Intelligent automobile end cloud model version collaborative management system and method

Abstract

The application provides a kind of intelligent automobile end cloud model version collaborative management system and method, it is related to intelligent automobile technical field.Intelligent automobile end cloud model version collaborative management system includes cloud and side.The cloud is used to respond to the cloud base model upgrade is monitored, determine and the side inference model of the cloud base model exists version dependency relationship;Compatibility evaluation result obtained by executing multidimensional compatibility evaluation to the side inference model is acquired, multidimensional compatibility evaluation includes interface compatibility evaluation, precision compatibility evaluation and performance compatibility evaluation;And, according to compatibility evaluation result and the cloud base model after upgrading, the update package corresponding to the side inference model is generated, and the update package is pushed to the side.The side is used to update the side inference model according to the update package.Through the cooperation of cloud and side, the automatic collaborative management of end cloud model version is realized, and the reliability and stability of inference service are improved.

Description

Technical Field

[0001] This application relates to the field of intelligent vehicle technology, and in particular to an intelligent vehicle edge-cloud model version collaborative management system and method. Background Technology

[0002] Intelligent vehicle cockpit systems extensively utilize deep learning models to provide functions such as intent recognition, driving behavior prediction, and voice understanding. These functional models typically employ a layered edge-cloud deployment architecture: the cloud continuously collects data, trains and iteratively upgrades the basic model; the on-device computing unit (domain controller) runs an inference model optimized for the vehicle hardware, providing low-latency real-time services. There is a version dependency between the on-device inference model and the cloud-based basic model. When the cloud-based basic model is upgraded, the on-device inference model may become incompatible with the upgraded version, leading to inference service anomalies or even service interruptions—a problem known as "edge-cloud version mismatch."

[0003] In related technologies, edge devices are grouped into multiple groups based on their correlation with each other. When the inference result of the edge-side inference model deviates from the current data distribution or a state change is detected, the model of the corresponding edge device group is automatically refreshed, and a full model update is pushed to that group of edge devices. However, even with this intelligent vehicle edge-cloud model collaborative management method, inference service anomalies still exist in some scenarios. Summary of the Invention

[0004] This application provides a collaborative management system and method for intelligent vehicle edge-cloud model versions, which can realize automated collaborative management of edge-cloud model versions and improve the reliability and stability of inference services.

[0005] Firstly, this application provides an intelligent vehicle edge-cloud model version collaborative management system, including a cloud platform and an edge platform, wherein:

[0006] In the cloud, it is used to respond to the detection of cloud base model upgrades, identify the edge inference models that have version dependencies on the cloud base model, obtain the compatibility assessment results obtained by performing multi-dimensional compatibility assessment on the edge inference models, including interface compatibility assessment, accuracy compatibility assessment and performance compatibility assessment, and generate the update package corresponding to the edge inference model based on the compatibility assessment results and the upgraded cloud base model, and push the update package to the edge.

[0007] On the endpoint, it is used to respond to received update packets and update the endpoint inference model based on the update packets.

[0008] In one possible implementation, the intelligent vehicle edge-cloud model version collaborative management system provided in this application includes at least one of the following:

[0009] Interface compatibility assessment includes: comparing the input tensor specifications and / or output tensor specifications registered by the end-side inference model with the interface declaration of the upgraded cloud-based basic model; if the input tensor specifications are inconsistent with the interface declaration, or the output tensor specifications are inconsistent with the interface declaration, the interface is determined to be incompatible.

[0010] Accuracy compatibility assessment includes: running the edge-side inference model and the upgraded back-end inference model on a pre-defined calibration dataset to obtain the accuracy degradation and relative entropy of the edge-side inference model and the upgraded back-end inference model. The upgraded back-end inference model is generated based on the upgraded cloud-based basic model. If the accuracy degradation exceeds a preset degradation threshold or the relative entropy exceeds a preset relative entropy threshold, it is determined to be incompatible with accuracy.

[0011] Performance compatibility assessment includes: estimating the inference latency increment and video memory increment of the edge inference model on the target hardware based on the model structure performance of the upgraded cloud base model; if the inference latency increment exceeds the latency increment limit or the video memory increment exceeds the video memory increment limit, it is determined to be performance incompatible.

[0012] In one possible implementation, when the cloud generates the update package corresponding to the edge inference model based on the compatibility assessment results and the upgraded cloud base model, it is specifically used for:

[0013] Determine the minimum update strategy corresponding to the compatibility assessment results. The minimum update strategy is used to minimize the cloud-end transmission volume and / or minimize the number of writes to the end-side storage.

[0014] Based on the minimum update strategy and the upgraded cloud-based base model, an update package corresponding to the edge-side inference model is generated.

[0015] In one possible implementation, determining the minimum update strategy corresponding to the compatibility assessment results includes:

[0016] If the compatibility assessment results are that the interface is compatible, the accuracy is compatible, and the performance is compatible, then the minimum update strategy corresponding to the compatibility assessment results is determined to be the no-update strategy.

[0017] If the compatibility assessment result is that the interface is incompatible, the accuracy is compatible, and the performance is compatible, then the minimum update strategy corresponding to the compatibility assessment result is determined to be the adaptation layer injection strategy.

[0018] If the compatibility assessment result indicates incompatibility in accuracy but compatibility in performance, the minimum update strategy corresponding to the compatibility assessment result is determined to be the incremental parameter difference strategy.

[0019] If the compatibility assessment result is performance incompatibility, the minimum update strategy corresponding to the compatibility assessment result is determined to be the full model replacement strategy.

[0020] If the compatibility assessment result indicates that the interface is incompatible and the accuracy is incompatible, the minimum update strategy corresponding to the compatibility assessment result is determined to be the full model replacement strategy.

[0021] In one possible implementation, the end side is specifically used for:

[0022] Based on the update package, candidate versions of the edge inference model are obtained;

[0023] Candidate versions are hot-loaded in parallel with candidate states, and canary inference verification is performed based on the candidate versions to obtain the verification results corresponding to the candidate versions;

[0024] If the verification result indicates that the verification passed, the candidate version will be submitted as the active version.

[0025] In one possible implementation, the end side is also used for:

[0026] If the verification result indicates that the verification failed, conflict information is reported to the cloud. The conflict information is used to indicate the version dependency relationship between the cloud base model and the edge inference model after the update and upgrade.

[0027] In one possible implementation, the intelligent vehicle edge-cloud model version collaborative management system includes multiple edge devices, and pushes update packages to these edge devices, including:

[0028] Based on geographic location and / or hardware configuration, representative samples are extracted from multiple endpoints.

[0029] The update package is pushed to the representative samples to obtain the verification results of the representative samples' canary reasoning verification of the update package;

[0030] By using differential privacy protection technology, the verification results corresponding to representative samples are aggregated and distributed for evaluation to obtain aggregated distributed evaluation results.

[0031] If the aggregated distributed evaluation results indicate that the verification is successful, the update package is pushed to non-representative samples on multiple endpoints.

[0032] In one possible implementation, when determining the edge inference model that has a version dependency with the cloud-based base model, the cloud specifically uses the following:

[0033] Based on the set depth limit, a breadth-first search technique is applied to traverse the version dependency graph to identify the edge inference models that have version dependencies with the cloud-based basic model. The version dependency graph is used to reflect the direct and indirect dependencies between the edge inference models and the cloud-based basic model.

[0034] Correspondingly, on the device side, it is also used to push the version confirmation information corresponding to the update package to the cloud when the device side inference model is successfully updated according to the update package;

[0035] In the cloud, it is also used to update the version number and status of the edge-side inference model in the version dependency graph based on version confirmation information.

[0036] Secondly, this application provides a method for collaborative management of intelligent vehicle edge-cloud model versions, applied to the cloud in the intelligent vehicle edge-cloud model version collaborative management system as described in the first aspect above. The intelligent vehicle edge-cloud model version collaborative management method includes:

[0037] The system detects an upgrade to the cloud-based basic model and identifies the edge-side inference model that has a version dependency relationship with the cloud-based basic model.

[0038] Obtain the compatibility evaluation results obtained by performing a multi-dimensional compatibility evaluation on the peer-side inference model. The multi-dimensional compatibility evaluation includes interface compatibility evaluation, accuracy compatibility evaluation, and performance compatibility evaluation.

[0039] Based on the compatibility assessment results and the upgraded cloud-based basic model, an update package corresponding to the edge inference model is generated and pushed to the edge. The edge uses the update package to update the edge inference model.

[0040] Thirdly, this application provides a method for collaborative management of intelligent vehicle edge-cloud model versions, applied to the edge side of the intelligent vehicle edge-cloud model version collaborative management system as described in the first aspect above. The intelligent vehicle edge-cloud model version collaborative management method includes:

[0041] Receive update packages pushed from the cloud. The update packages are obtained by the cloud executing the intelligent vehicle end-to-cloud model version collaborative management method as described in the second aspect above.

[0042] Based on the update package, candidate versions of the edge inference model are obtained;

[0043] Candidate versions are hot-loaded in parallel with candidate states, and canary inference verification is performed based on the candidate versions to obtain the verification results corresponding to the candidate versions;

[0044] If the verification result indicates that the verification is successful, the candidate version will be submitted as the active version of the edge inference model.

[0045] Fourthly, this application provides an electronic device, including: a memory and a processor;

[0046] The memory stores the instructions that the computer executes;

[0047] The processor executes computer execution instructions stored in memory, causing the processor to perform various possible implementations of the second or third aspect above.

[0048] Fifthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a device such as a processor, are used to implement various possible embodiments of the second or third aspect above.

[0049] In a sixth aspect, this application provides a computer program product, including a computer program that, when executed by a device such as a processor, implements various possible implementations of the second or third aspect described above.

[0050] The intelligent vehicle edge-cloud model version collaborative management system and method provided in this application detects upgrades to the cloud-based basic model through cloud response monitoring, identifies edge-side inference models with version dependencies on the cloud-based basic model, and automates and simplifies dependency tracing. By acquiring the compatibility assessment results obtained from performing a multi-dimensional compatibility assessment on the edge-side inference model—including interface compatibility assessment, accuracy compatibility assessment, and performance compatibility assessment—a comprehensive and standardized compatibility assessment of the edge-side inference model and the upgraded cloud-based basic model can be achieved from three core dimensions: data interaction, inference performance, and hardware adaptability, thereby improving the reliability of the inference service from the assessment stage. Based on the compatibility assessment results and the upgraded cloud-based basic model, an update package corresponding to the edge-side inference model is generated, ensuring that the content of the update package matches the actual adaptation requirements of the edge-side inference model. The update package is then pushed to the edge, improving the efficiency and accuracy of version updates, thereby ensuring the precision and efficiency of edge-cloud model version updates and providing update content support for the stable operation of the inference service. Upon receiving the update packet via the endpoint response, the endpoint inference model is updated accordingly, ensuring that the endpoint inference model and the cloud-based basic model maintain an efficient and stable adaptation state. This further enables automated collaborative management of endpoint and cloud model versions, improving the reliability and stability of the inference service. Attached Figure Description

[0051] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0052] Figure 1 A schematic diagram of the structure of the intelligent vehicle end-to-cloud model version collaborative management system provided in this application embodiment;

[0053] Figure 2 A schematic diagram of an application of the intelligent vehicle edge-cloud model version collaborative management system provided in this application embodiment;

[0054] Figure 3 An application flowchart of the intelligent vehicle end-to-cloud model version collaborative management system provided in this application embodiment;

[0055] Figure 4This is a timing interaction diagram for end-to-cloud version collaboration provided in an embodiment of this application;

[0056] Figure 5 A flowchart illustrating the intelligent vehicle edge-cloud model version collaborative management method provided in this application embodiment;

[0057] Figure 6 Another flowchart illustrating the intelligent vehicle end-to-cloud model version collaborative management method provided in this application embodiment;

[0058] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0059] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0060] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0061] The inventors discovered that in the existing intelligent vehicle edge-cloud model collaborative management method, the update triggering mechanism only relies on the prediction deviation threshold and does not check the interface protocol compatibility between the new and old models. Therefore, when the interface protocols are incompatible, even if the existing intelligent vehicle edge-cloud model collaborative management method is used, there will still be problems with inference service anomalies.

[0062] To overcome the aforementioned limitations, this application provides an intelligent vehicle edge-cloud model version collaborative management system. After detecting an upgrade of the cloud-based basic model, the system identifies edge-side inference models that have version dependencies on the cloud-based basic model. A multi-dimensional compatibility assessment, including interface compatibility evaluation, is performed on the edge-side inference models to obtain the compatibility assessment results. Furthermore, an update package is generated based on the compatibility assessment results and the upgraded cloud-based basic model and pushed to the edge. The edge updates its inference model according to the update package. Through this interaction between the cloud and the edge, automated collaborative management of edge-cloud model versions can be achieved, improving the reliability and stability of the inference service.

[0063] This application applies to edge-cloud collaborative inference scenarios in intelligent vehicle cockpit systems. For example, in this scenario, the cloud is deployed at the vehicle manufacturer (OEM)'s (Original Equipment Manufacturer) Artificial Intelligence (AI) training platform, responsible for continuous model training, version management, and deployment. Deployment can be based on Over-The-Air (OTA) technology. The edge runs on the vehicle's Domain Control Unit (DCU), equipped with an onboard Neural Processing Unit (NPU) with 4-8 TOPS of computing power, interacting with the cloud via a 5G / LTE OTA secure channel. Here, TOPS stands for trillions of operations per second, a unit of computing power; LTE typically refers to 4G networks.

[0064] Typical edge-cloud collaborative reasoning scenarios include edge-side reasoning models such as intent recognition models, driving behavior prediction models, and speech understanding models, all of which rely on the continuous updating of basic perception models (such as feature extraction backbone networks) in the cloud.

[0065] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0066] Figure 1 This is a schematic diagram of the structure of the intelligent vehicle edge-cloud model version collaborative management system provided in an embodiment of this application. Figure 1 As shown, the intelligent vehicle edge-cloud model version collaborative management system 10 includes: a cloud 101 and an edge 102, wherein:

[0067] Cloud 101 is used to respond to the detection of cloud base model upgrades, identify the edge inference models that have version dependencies on the cloud base model, obtain the compatibility assessment results obtained by performing multi-dimensional compatibility assessment on the edge inference models, including interface compatibility assessment, accuracy compatibility assessment and performance compatibility assessment, and generate the update package corresponding to the edge inference model based on the compatibility assessment results and the upgraded cloud base model, and push the update package to the edge.

[0068] For example, Cloud101 monitors the version upgrade status of the cloud base model in real time. After detecting that the cloud base model has completed the upgrade, it identifies the edge inference model that has a version dependency relationship with the cloud base model.

[0069] Furthermore, a multi-dimensional compatibility assessment is performed on the edge-side inference model, including interface compatibility assessment, accuracy compatibility assessment, and performance compatibility assessment. From the three levels of data interaction, inference effect, and hardware adaptability, the multi-dimensional adaptability of the edge-side inference model and the upgraded cloud-based basic model is verified to obtain the compatibility assessment results.

[0070] Optionally, compatibility assessment results can be obtained online or offline using the methods described above. Specifically, when the cloud-based base model training is complete, i.e., when the upgrade is complete, a multi-dimensional compatibility assessment is performed, and the compatibility assessment results are stored in the cloud model repository. The online synchronization process can directly reuse the pre-assessment results, thereby reducing online decision latency from seconds to milliseconds.

[0071] Furthermore, based on the above compatibility assessment results and the upgraded cloud-based basic model, an update package matching the actual adaptation requirements of the edge-side inference model is generated, and the update package is pushed to the edge-side via the OTA secure channel.

[0072] The endpoint 102 is used to respond to the received update packet and update the endpoint inference model according to the update packet.

[0073] For example, the OTA security channel performs integrity and legality checks on the update package to be transmitted. After the checks pass, the terminal 102 responds to the version update instruction from the cloud 101 and updates the terminal inference model based on the update information specified in the update package. This achieves version adaptation between the terminal inference model and the upgraded cloud base model, ensuring the reliable operation of the inference service.

[0074] The intelligent vehicle edge-cloud model version collaborative management system provided in this application detects upgrades to the cloud-based basic model through cloud response monitoring, identifies edge-side inference models with version dependencies on the cloud-based basic model, and automates and simplifies dependency tracing. By acquiring the compatibility assessment results obtained from performing a multi-dimensional compatibility assessment on the edge-side inference model—including interface compatibility assessment, accuracy compatibility assessment, and performance compatibility assessment—it achieves a comprehensive and standardized compatibility assessment of the edge-side inference model and the upgraded cloud-based basic model from three core dimensions: data interaction, inference performance, and hardware adaptability, thereby improving the reliability of the inference service from the assessment stage. Based on the compatibility assessment results and the upgraded cloud-based basic model, an update package corresponding to the edge-side inference model is generated, ensuring that the update package content matches the actual adaptation requirements of the edge-side inference model. The update package is then pushed to the edge, improving the efficiency and accuracy of version updates, thereby ensuring the precision and efficiency of edge-cloud model version updates and providing update content support for the stable operation of the inference service. Upon receiving the update packet via the endpoint response, the endpoint inference model is updated accordingly, ensuring that the endpoint inference model and the cloud-based basic model maintain an efficient and stable adaptation state. This further enables automated collaborative management of endpoint and cloud model versions, improving the reliability and stability of the inference service.

[0075] Based on the above embodiments, the intelligent vehicle cloud model version collaborative management system provided in this application may include at least one of the following:

[0076] Interface compatibility assessment may include: comparing the input tensor specifications and / or output tensor specifications registered by the end-side inference model with the interface declaration of the upgraded cloud-based basic model; if the input tensor specifications are inconsistent with the interface declaration, or the output tensor specifications are inconsistent with the interface declaration, the interface is determined to be incompatible.

[0077] Accuracy compatibility assessment may include: running the edge-side inference model and the upgraded back-end inference model on a pre-defined calibration dataset to obtain the accuracy degradation and relative entropy of the edge-side inference model and the upgraded back-end inference model. The upgraded back-end inference model is generated based on the upgraded cloud-based basic model. If the accuracy degradation exceeds a preset degradation threshold or the relative entropy exceeds a preset relative entropy threshold, it is determined to be incompatible with accuracy.

[0078] Performance compatibility assessment may include: estimating the inference latency increment and video memory increment of the edge inference model on the target hardware based on the model structure performance of the upgraded cloud base model; if the inference latency increment exceeds the latency increment limit or the video memory increment exceeds the video memory increment limit, it is determined to be performance incompatible.

[0079] Because existing technologies lack the ability to automatically assess multi-dimensional compatibility and cannot distinguish different failure modes of the interface layer, accuracy layer, and performance layer, version collaborative management of the edge-cloud model is carried out by including interface compatibility assessment, accuracy compatibility assessment, and performance compatibility assessment.

[0080] For example, regarding interface compatibility assessment, if the interface protocol version of the cloud-based base model corresponding to the edge inference model changes, an interface compatibility assessment is triggered. Specifically, the input tensor specifications registered by the edge inference model are compared with the interface declaration of the upgraded cloud-based base model, or the output tensor specifications registered by the edge inference model are compared with the interface declaration of the upgraded cloud-based base model, or the input tensor specifications and output tensor rules registered by the edge inference model are compared with the interface declaration (input tensor shape, output tensor shape, element data type, and interface protocol version number) of the upgraded cloud-based base model.

[0081] Optionally, if the input tensor specifications are inconsistent with the interface declaration, or if the output tensor specifications are inconsistent with the interface declaration, the interface is determined to be incompatible. Optionally, if the input tensor specifications and output tensor specifications are consistent with the interface declaration, the interface is determined to be compatible.

[0082] The input and output tensor specifications are pre-registered and filed fixed information, representing the interface capabilities currently supported by the edge inference model. The interface declaration of the upgraded cloud-based basic model is a standardized interface specification that is simultaneously released to the public when the cloud-based basic model is upgraded, representing the interaction standards required by the new cloud version.

[0083] Optionally, for accuracy compatibility assessment, the original edge-side inference model and the edge-side inference model generated based on the upgraded cloud-based base model (i.e., the upgraded back-end inference model) are run on a cloud-calibrated dataset, respectively, and the accuracy degradation and relative entropy of the corresponding inference results for both are calculated. The accuracy degradation is the absolute difference between the two, used to quantify the overall accuracy decrease of the edge-side inference model relative to the upgraded back-end inference model. The relative entropy is a distributional quantification index used to measure the degree of deviation of the probability distribution of the inference results from the edge-side inference model relative to the probability distribution of the upgraded back-end inference model.

[0084] If the accuracy degradation exceeds a preset degradation threshold (e.g., 2%), or the relative entropy exceeds a preset relative entropy threshold (e.g., 0.05), the accuracy is determined to be incompatible. Optionally, if the accuracy degradation does not exceed a preset degradation threshold and the relative entropy does not exceed a preset relative entropy threshold, the accuracy is determined to be compatible.

[0085] It is understandable that cloud calibration datasets refer to standardized cockpit business datasets prepared in advance in the cloud, such as voice commands and driving behavior data, which serve as a unified benchmark for judging model accuracy.

[0086] The upgraded backend inference model is pre-generated after the upgraded base model has been trained. In other words, after obtaining the upgraded base model, it is lightweighted, quantized, and compiled to obtain the upgraded backend inference model.

[0087] For performance compatibility assessment, based on the model structure performance of the upgraded cloud-based base model, the latency inference increment and memory increment of the edge inference model on the target hardware (such as the current vehicle domain controller) are estimated. If the inference latency increment exceeds the upper limit of the inference latency increment, such as 20%, or the memory increment is higher than the upper limit of the memory increment, such as 15%, it is determined to be performance incompatible. Optionally, if the inference latency increment does not exceed the upper limit of the inference latency increment and the memory increment is higher than the upper limit of the memory increment, it is determined to be performance compatible.

[0088] Optionally, the model performance structure is obtained by performing a full-dimensional performance analysis on the upgraded cloud-based base model, extracting its core performance characteristics during inference, such as network layer complexity, tensor computation volume, parameter size, and memory access frequency, and then analyzing, quantifying, and simulating these core performance characteristics. The inference latency increment represents the single inference latency of the edge target hardware during the inference of the cloud-based base model after the collaborative upgrade, relative to the single inference latency of the cloud-based base model before the collaborative upgrade. The memory increment represents the memory usage of the edge target hardware during the inference of the cloud-based base model after the collaborative upgrade, relative to the memory usage of the cloud-based base model before the collaborative upgrade.

[0089] Interface compatibility assessments mitigate runtime crashes, accuracy compatibility assessments alleviate inference accuracy degradation, and performance compatibility assessments ensure that the model size does not exceed the onboard computing budget. These multi-dimensional compatibility assessments significantly improve the comprehensiveness and targeted nature of version collaborative management.

[0090] Optionally, when the cloud generates the update package corresponding to the edge inference model based on the compatibility assessment results and the upgraded cloud base model, it specifically uses the following methods: determining the minimum update strategy corresponding to the compatibility assessment results, whereby the minimum update strategy is used to minimize the cloud-edge transmission volume and / or minimize the number of edge-side storage writes; and generating the update package corresponding to the edge inference model based on the minimum update strategy and the upgraded cloud base model.

[0091] Since existing technologies lack a minimum update strategy generation mechanism, they can usually only perform full model replacement, resulting in unnecessary OTA bandwidth and write losses. Therefore, by determining the minimum update strategy corresponding to the compatibility assessment results, the update transmission volume can be effectively reduced.

[0092] For example, based on the compatibility evaluation results across three dimensions—interface, accuracy, and performance—a minimum update strategy corresponding to the current edge-side inference model's adaptation requirements is determined using preset strategy matching rules. This minimum update strategy aims to minimize the amount of update packets transmitted from the cloud to the edge, and / or minimize the number of storage writes on the edge, thereby reducing the transmission pressure on the vehicular communication network, lowering read / write overhead on the edge-side storage hardware, and improving the execution efficiency of edge-side update operations.

[0093] Furthermore, after determining the appropriate minimum update strategy, a dedicated update package is generated for each edge inference model based on the determined minimum update strategy and the upgraded cloud-based base model. This ensures that the update package content contains no redundant update data and achieves compatibility between the edge inference model and the upgraded cloud-based base model. The generated update package may include: the minimum update strategy, update content, target edge inference model, target update version number, and a checksum (to verify that the update package is not corrupted or tampered with).

[0094] Optionally, when the update packet transmission times out or integrity verification fails, the endpoint maintains the current version and triggers an exponential backoff retransmission strategy. The maximum number of retransmissions is configurable, such as 3. For example, if the first attempt fails, wait 1 second before retransmitting; if the second attempt fails, wait 2 seconds before retransmitting; if the third attempt fails, wait 4 seconds before retransmitting. A maximum of 3 retries are allowed; if any further failures occur, the process stops.

[0095] Further, determining the minimum update strategy corresponding to the compatibility assessment result can include: if the compatibility assessment result is interface compatible, accuracy compatible, and performance compatible, the minimum update strategy corresponding to the compatibility assessment result is determined to be the no-update strategy. If the compatibility assessment result is interface incompatible, accuracy compatible, and performance compatible, the minimum update strategy corresponding to the compatibility assessment result is determined to be the adaptation layer injection strategy. If the compatibility assessment result is accuracy incompatible but performance compatible, the minimum update strategy corresponding to the compatibility assessment result is determined to be the incremental parameter difference strategy. If the compatibility assessment result is performance incompatible, the minimum update strategy corresponding to the compatibility assessment result is determined to be the full model replacement strategy. If the compatibility assessment result is interface incompatible and accuracy incompatible, the minimum update strategy corresponding to the compatibility assessment result is determined to be the full model replacement strategy.

[0096] For example, minimal update strategies may include: no-update strategy, adaptation layer injection strategy, incremental parameter difference strategy, and full model replacement strategy.

[0097] Optionally, if the compatibility assessment results show that the interface is compatible, the accuracy is compatible, and the performance is compatible, the cloud determines that the edge inference model and the upgraded cloud base model can run together directly without any modification to the model itself. In this case, the no-update strategy is selected, and only the metadata of the edge inference model is refreshed to synchronize the version association information of the upgraded cloud base model.

[0098] If the compatibility assessment results indicate interface incompatibility, accuracy compatibility, and performance compatibility, and the cloud determines that the edge-side inference model only has a surface-level interface adaptation issue, with no abnormalities in core inference consumption or hardware capacity, then the adaptation layer injection strategy is selected. Specifically, a lightweight interface conversion adaptation layer is generated. This layer contains only customized lightweight logic such as tensor specification conversion and protocol version translation, with a package size of less than 5MB. For example, tensor dimensions can be adapted using a linear projection layer.

[0099] If the compatibility assessment results indicate incompatibility in accuracy but compatibility in performance, and the cloud determines that the core inference accuracy of the edge-side inference model has degraded but the hardware can handle the current operational requirements, then an incremental parameter difference strategy is selected. Specifically, using the edge-side inference model as a benchmark, and combining it with the upgraded backend-side inference model, the parameter differences between the two are extracted and a parameter difference package is generated. This parameter difference package only contains the parameter parts that have changed in the model, and the package size is approximately 10%-30% of the full model package.

[0100] If the compatibility assessment result indicates performance incompatibility, the cloud-based determination of the edge-side inference model suggests insufficient hardware capacity, making partial lightweight updates incompatible. In this case, a full model replacement strategy is selected. Alternatively, if the compatibility assessment result indicates both interface and accuracy incompatibility, the cloud-based determination of the edge-side inference model suggests dual core adaptation issues in both interface and accuracy, making partial lightweight updates incompatible. In this case, a full model replacement strategy is selected. Specifically, the complete model file pre-stored in the cloud repository is directly retrieved, i.e., the backend-side inference model is upgraded, and the original edge-side inference model is downgraded to a rollback version.

[0101] The complete model file can be transferred from the cloud repository to the device via an OTA secure channel. A complete model file refers to the entire model that can be directly run on the device, and may include: model structure, all parameter weights, inference engine configuration, hardware adaptation code, and interface definitions.

[0102] It is important to note that, while ensuring compatibility, the adaptation layer injection strategy takes precedence over the incremental parameter differential strategy, and the incremental parameter differential strategy takes precedence over the full model replacement strategy, in order to minimize OTA transmission volume and the number of writes to the end-side storage.

[0103] By dynamically selecting a minimum update strategy, OTA transmission volume and the number of writes to edge storage are reduced. Adaptation layer injection and incremental differential strategies only fix specific issues, reducing the resource waste of full replacements. By combining the results of the three-layer compatibility assessment, the update strategy is ensured to match actual needs, improving the efficiency and cost-effectiveness of edge-cloud collaborative updates.

[0104] In some embodiments, the endpoint is specifically used to: obtain candidate versions of the endpoint inference model based on the update package; hot-load the candidate versions in parallel with the candidate states; perform canary inference verification based on the candidate versions to obtain the verification results corresponding to the candidate versions; if the verification result indicates that the verification passed, the candidate version is submitted as the active version.

[0105] For example, based on the uploaded update package, the update package is parsed and executed according to the minimum update strategy specified by the cloud, and the original edge-side inference model is fine-tuned to obtain candidate versions of the edge-side inference model. The candidate versions are then hot-loaded in parallel in the background as inactive candidate versions. Throughout the loading process, the current active version, i.e., the original edge-side inference model, is maintained to run normally and continuously handle vehicle inference service requests.

[0106] Hot loading can be understood as a loading method that does not stop the original model, restart the inference engine, or occupy additional core business resources. The loading process is completed in the background on the client side, utilizing the remaining computing power / memory of the domain controller, without affecting the real-time inference service of the original model. The candidate state refers to the "isolated operation, no business intervention" pending verification state after the new model is loaded. It only completes the model initialization, parameter loading, and inference engine adaptation, and does not receive any actual cockpit business inference requests, forming strict resource and business isolation from the original active model.

[0107] Alternatively, candidate versions are obtained in the following way:

[0108] If the minimum update strategy is "no update required," a new set of metadata tags matching the upgraded cloud-based base model is added to the current active version to form a candidate version. If the minimum update strategy is "adapter layer injection," based on the current active version, the adapter layer is mounted on the interaction node between the original edge inference model and the cloud according to the mounting rules defined in the adapter layer, and the original edge inference model and the adapter layer are treated as a whole as a candidate version.

[0109] If the minimum update strategy is an incremental parameter difference strategy, the parameter difference data in the parameter difference package is extracted. Based on the current active version, the parameters are incrementally replaced / fused in the background to update the model parameters, and the newly fine-tuned model is used as the candidate version. If the minimum update strategy is a full model replacement strategy, the entire model file is loaded and initialized directly in the background, and the newly loaded and initialized complete model is used as the candidate version.

[0110] Furthermore, after loading is complete, canary inference verification is performed to obtain the verification results corresponding to the candidate versions. It can be understood that the core of canary inference verification lies in verifying the actual operating effect of the candidate versions in an isolated environment through inference using small batches of standardized calibration samples. Specifically, continuous, non-interventional batch inference is performed on the candidate versions based on the cloud-based calibration dataset, and the inference process is consistent with the execution logic of actual in-vehicle business inference.

[0111] Optionally, if the verification result indicates that the verification passed, for example, if the average confidence score of five consecutive inferences is higher than a preset confidence threshold, such as 0.6, and the distribution of inference results matches the expected range, then the candidate version is submitted as the active version to handle subsequent in-vehicle inference service requests, thereby enabling version updates of the edge inference model and achieving efficient collaborative operation with the upgraded cloud-based basic model. Furthermore, the original active version is downgraded to a rollback version and stored locally on the edge as an emergency backup to ensure the security of the switchover process.

[0112] It is important to note that the current active version and the candidate version can prepare canary inference simultaneously. Before the candidate version is submitted as an active version, the current active version continues to provide inference services without interruption.

[0113] As one possible implementation, the edge side is also used to: if the verification result indicates that the verification fails, report conflict information to the cloud. The conflict information is used to indicate the version dependency relationship between the cloud base model and the edge inference model after the update and upgrade.

[0114] Because existing technologies lack version conflict detection and automatic rollback protection, manual intervention is required once an update causes inference anomalies, resulting in long recovery times. Therefore, when verification fails, conflict detection and automatic rollback are performed, and the conflict information is reported to the cloud.

[0115] For example, during the inference verification process, the edge continuously monitors the canary inference metrics. When consecutive verification failures occur during the canary inference verification process, such as three or more instances where the confidence level is lower than the preset confidence threshold, or when the inference result is invalid, such as when the inference result is not numerical or infinite, the edge will automatically switch back to the active version (memory-level switching with a delay of less than 1 second), that is, the current running version will be rolled back to the original active version to ensure the continuity and stability of the edge inference service.

[0116] After the version rollback operation is triggered, the client side synchronously uploads conflict information to the cloud. This conflict information indicates that there is a version dependency mismatch between the cloud base model and the client side inference model after the model update and upgrade, providing a basis for subsequent model version adaptation and dependency optimization.

[0117] Optionally, the conflict information may include: the reason for the rollback, the candidate version number of the failure, the stable version number to be switched back to, and the precise timestamp of the rollback.

[0118] In one possible implementation, the intelligent vehicle edge-cloud model version collaborative management system may include multiple edge devices. In some embodiments, pushing update packages to the edge devices may include: extracting representative samples from multiple edge devices based on geographic location and / or hardware configuration; pushing update packages to the representative samples to obtain verification results of canary inference verification of the update packages by the representative samples; performing a summary distributed evaluation on the verification results corresponding to the representative samples using differential privacy protection technology to obtain a summary distributed evaluation result; if the summary distributed evaluation result indicates that the verification passed, pushing update packages to non-representative samples among the multiple edge devices.

[0119] For example, the intelligent vehicle edge-cloud model version collaborative management system can include multiple edge devices. When pushing update packages from the cloud to the edge devices, representative samples can be extracted from multiple edge devices based on their geographical distribution and / or hardware configuration (such as NPU computing power and memory specifications), for example, 1%-5% of the samples. The cloud pushes update packages to the extracted representative samples through an OTA secure channel, performs canary inference verification of the update packages in parallel on the representative samples, and collects indicators such as the mean confidence level and the output distribution fit to obtain the verification results corresponding to the representative samples.

[0120] Furthermore, after obtaining the verification results of representative samples, the verification results are processed using differential privacy protection technology. By adding controllable privacy-preserving noise during the data aggregation process and using a distributed data fusion algorithm, distributed aggregation and evaluation of all verification results are carried out while protecting the privacy of local running data on each end.

[0121] Specifically, a comprehensive analysis of the update package's adaptation effectiveness across different regions and hardware configurations is conducted. This analysis generates a summarized distributed evaluation result that reflects the overall adaptation level. This summarized distributed evaluation result serves as the basis for the decision to push the update package to the entire fleet. Based on this summarized distributed evaluation result, it can be determined whether the update package is compatible with the entire fleet.

[0122] Optionally, if the aggregated distributed evaluation results indicate successful verification, the cloud will batch push update packages to non-representative sample endpoints from multiple endpoints, achieving efficient and secure deployment of update packages across all endpoints. This can reduce the probability of systemic failures due to differences in endpoint environments by more than 80%. If the aggregated distributed evaluation results indicate unsuccessful verification, the push will be stopped or the update strategy will be optimized.

[0123] Differential privacy protection refers to techniques that protect the privacy of sample data by adding noise or encryption. Summarized distributed evaluation results can include aggregated data such as the confidence mean and the degree of fit of the output distribution.

[0124] By ensuring diverse coverage of representative samples, the evaluation results are made more universal, reducing the probability of decision-making errors caused by environmental deviations of individual vehicles. Differential privacy protection ensures data security and enhances user trust in OTA updates. Based on aggregated distributed evaluation results, it determines whether the update package is suitable for the entire fleet, reducing the risk of systemic failures due to differences in edge-side environments and improving the reliability and security of large-scale fleet collaborative management.

[0125] Optionally, when determining the edge inference model that has a version dependency relationship with the cloud base model, the cloud specifically uses: based on a set depth limit, a breadth-first search technique is applied to traverse the version dependency graph to determine the edge inference model that has a version dependency relationship with the cloud base model. The version dependency graph is used to reflect the direct and indirect dependency relationships between the edge inference model and the cloud base model.

[0126] In some embodiments, the endpoint is also configured to push version confirmation information corresponding to the update package to the cloud when the endpoint inference model is successfully updated according to the update package.

[0127] In some embodiments, the cloud is also used to update the version number and status of the edge-side inference model in the version dependency graph based on version confirmation information.

[0128] Because existing technologies lack a structured representation of edge-cloud model version dependencies, it is impossible to accurately identify the scope of edge inference models affected by upgrades to the cloud-based base model. Therefore, a Version Dependency Graph (VDG) is constructed to represent the dependency relationship between edge inference models and the cloud-based base model. Optionally, the version dependency graph is constructed in the following way:

[0129] Version metadata of all deployed models is read from the cloud-based base model repository, and a version dependency graph is constructed in the form of a Directed Acyclic Graph (DAG). Graph nodes contain model identifiers, version numbers, interface protocol versions, feature dimensions, and output format specifications. Directed edges in the graph contain dependency constraint types, constraint values, and tolerance ranges, pointing from downstream edge-side inference models to upstream cloud-based base models. Each node uniquely corresponds to one model instance: one cloud-based base model version / one edge-side inference model version. Node-internal storage contains core attributes for determining model compatibility.

[0130] For example, when the cloud-based base model is upgraded, a version change event is automatically generated, including: a unique identifier for the upgraded cloud model, the old version number of the cloud model, the new version number, and a summary of the core differences in this upgrade. Based on this version change event, a Breadth-First Search (BFS) is triggered. Starting from the root node of the version change event, it expands the dependent nodes layer by layer, traversing all direct and indirect dependent nodes related to the version change event to identify the edge inference models that have version dependencies on the cloud-based base model. During the traversal, the traversal range is controlled by a set depth limit (e.g., 3 levels) to balance the comprehensiveness of the traceability and the efficiency of the traversal.

[0131] As can be understood, BFS refers to a graph traversal algorithm that expands nodes hierarchically to accurately identify affected edge inference models. For example, when upgrading cloud models, BFS starts from the root node (the cloud base model) and expands dependent nodes layer by layer to ensure coverage of all directly and indirectly dependent edge inference models.

[0132] In some embodiments, if the edge-side inference model is successfully updated according to the update package, the edge can also push version confirmation information corresponding to the update package to the cloud. The version confirmation information may include: edge-side unique identifier, target model ID, updated target version number, update completion timestamp, current model activity status, candidate version status, etc.

[0133] Furthermore, after the version confirmation information is pushed to the cloud from the device side, the cloud updates the version number and status of the device-side inference model in the version dependency graph based on the version confirmation information, completing one round of device-cloud version collaboration and ensuring the real-time performance and accuracy of the graph data. This process forms a closed-loop management system, ensuring the continuity of device-cloud version collaboration.

[0134] Specifically, based on the version confirmation information, the cloud retrieves the version dependency graph, locates the corresponding model node in the graph according to the unique identifier of the inference model on the client side, then updates the old version number in the graph to the new version number that is actually effective on the client side, and updates the status of the model node in the graph to the corresponding status such as "updated / active" or "verification failed / to be optimized" according to the status identifier in the version confirmation information. At the same time, it records the version update time, the matching cloud basic model version number and other traceability information.

[0135] By constructing a version dependency graph, resource waste and version synchronization issues are effectively mitigated. Combining a depth cap with BFS technology achieves a balance between accuracy and computational efficiency in version dependency tracking. Closed-loop control of edge-cloud version collaborative management is achieved through version status feedback and graph updates. Dynamic updates to the version dependency graph in the cloud ensure accurate tracking of the impact scope of subsequent upgrade events, improving the real-time nature and automation of version management.

[0136] Figure 2 This is a schematic diagram illustrating an application of the intelligent vehicle edge-cloud model version collaborative management system provided in an embodiment of this application. For example... Figure 2 As shown, the cloud-based components include: a Version Dependency Graph Management module (VDG management module), a Compatibility Assessment Engine (CAE), and an Update Strategy Generator (USG). The edge-side (vehicle domain controller) components include: a Version Sync Agent (VSA), a Rollback Controller (RC), and a Local Version Registry (LVR).

[0137] Optionally, the cloud and the device are connected via an OTA secure channel. The OTA secure channel uses Transport Layer Security (TLS) protocols, such as TLS 1.3 encrypted transmission, hash-based message authentication code (HMAC) integrity verification, and exponential backoff retransmission mechanisms to ensure the security, reliability, and stability of data transmission between the cloud and the device.

[0138] In the cloud, the VDG management module is used to: respond to detected upgrades to the cloud-based base model, traverse the version dependency graph, and identify the edge-side inference models that have version dependencies on the cloud-based base model. CAE is used to: perform multi-dimensional compatibility assessments on the edge-side inference models and obtain the compatibility assessment results. USG is used to: generate update packages corresponding to the edge-side inference models based on the compatibility assessment results and the upgraded cloud-based base model, and push the update packages to the edge via the OTA secure channel.

[0139] On the client side, VSA is used to: respond to received update packets, obtain candidate versions of the client-side inference model based on the update packets, hot-load candidate versions in parallel with candidate states, and perform canary inference verification on them to obtain verification results. If the verification passes, the candidate version is submitted as the active version of the client-side inference model. RC is used to: continuously monitor canary inference metrics. When consecutive verification failures occur, it automatically switches to a rollback version as the active version and uploads conflict information to the cloud to trigger a state update of the version dependency graph. LVR is used to: persistently record the version state of the client-side inference model, maintaining three states: active, candidate, and rollback.

[0140] Optionally, the cloud can employ a distributed cluster architecture to implement core functions. By deploying functions such as the VDG management module, CAE, and USG on a multi-node computing cluster, and relying on technologies such as distributed graph storage, parallel task scheduling, and microservice orchestration, it supports the collaborative management needs of massive multi-device cloud model versions, ensuring high performance, high reliability, and elastic scalability of cloud services. On the device side, an in-vehicle computing cluster can serve as the hardware foundation, deploying functions such as VSA, RC, and LVR on multiple in-vehicle computing nodes. Through distributed collaboration and parallel computing within the vehicle, efficient and stable execution of the entire device-side process can be achieved.

[0141] Figure 3 This is an application flowchart of the intelligent vehicle edge-cloud model version collaborative management system provided in an embodiment of this application. Figure 3 As shown, the version dependency graph is first initialized in the cloud. When the cloud model (cloud base model) is upgraded, a version change event is triggered synchronously. BFS technology is applied to traverse the version dependency graph and identify the edge inference models associated with the cloud base model. A multi-dimensional compatibility assessment is performed on the aforementioned edge inference models to obtain the compatibility assessment results. Based on the compatibility assessment results, a minimum update strategy is selected, and based on the update strategy and the upgraded cloud base model, a corresponding update package is generated and transmitted to the edge via the OTA secure channel. The edge receives the update package, obtains candidate versions based on the update package, performs parallel hot loading of candidate versions, and performs canary verification on them. If the verification passes, the candidate version is submitted as the active version, and its status is synchronized to the cloud. If the verification fails, conflict information is reported to the cloud, and the cloud updates the version dependency relationships based on the conflict information.

[0142] Figure 4 This is a timing interaction diagram for end-to-cloud version collaboration provided in an embodiment of this application. For example... Figure 4 As shown, after upgrading the cloud-based base model, the cloud training platform publishes the upgraded base model to the VDG management module in the cloud. The VDG management module traverses the version dependency graph using BFS to identify the edge-side inference models that have version dependencies on the cloud-based base model. CAE performs a multi-dimensional compatibility assessment on the edge-side inference models and obtains the corresponding compatibility assessment results. USG selects a minimum update strategy based on the compatibility assessment results and generates an update package corresponding to the edge-side inference model. After obtaining the update package, it is pushed to the OTA secure channel via TLS encryption. The OTA secure channel delivers the update package to the edge-side VSA. The edge-side VSA obtains candidate versions of the edge-side inference model based on the update package, performs parallel hot loading of candidate versions, and verifies them using canary inference. If the verification passes, version confirmation information is pushed to the VDG management module to update the node status of the version dependency graph. If the verification fails, conflict information is also pushed to the VDG management module to update the node status of the version dependency graph.

[0143] For example, for the intelligent vehicle cloud model version collaborative management system provided in this application embodiment, the relevant parameter configuration may include: the accuracy degradation threshold can be configured to 2%, or it can be configured within the range of 1%-5% according to the vehicle safety level; the relative entropy threshold can be configured to 0.05; the inference latency increment limit can be configured to 20%; the video memory increment limit can be configured to 15%; the canary inference times can be configured to 5 times; the confidence lower limit can be configured to 0.6; the graph traversal depth limit can be configured to 3 layers; the retransmission limit can be configured to 3 times; the backoff coefficient can be configured to 2; and the initial interval can be configured to 30 seconds.

[0144] For example, a passenger vehicle cockpit system deployed an intent recognition model M_intent v1.2 (edge-side) and a driving behavior prediction model M_pred v2.0 (edge-side), both of which rely on the cloud-based basic perception model M_base. When M_base was upgraded from v3.1 to v3.2, the VDG management module triggered a BFS traversal, identifying the two affected edge-side inference models, M_intent and M_pred.

[0145] Perform a three-layer compatibility assessment on M_intent:

[0146] First layer: M_base v3.2 output dimensions changed from 128 to 160, which is incompatible with the interface;

[0147] Second layer: The accuracy degradation is 0.8%, which is less than 2%, and the accuracy is compatible;

[0148] The third layer has a latency increment of 5%, which is less than 20% and is performance-compatible.

[0149] Based on the above compatibility assessment results, the adaptation layer injection strategy was selected to generate a dimension-aligned adaptation layer (linear projection layer with approximately 20K parameters), and the update package size was 2.3MB.

[0150] Perform a three-layer compatibility assessment on M_pred:

[0151] First layer: Interface specifications remain unchanged, and the interfaces are compatible;

[0152] Second layer: The accuracy degradation is 3.2%, which is higher than 2%, indicating incompatibility in accuracy;

[0153] The third layer has a latency increment of 8%, which is less than 20% and is performance-compatible.

[0154] Based on the above compatibility assessment results, the incremental differential strategy was selected, and a differential weighted package of 17MB was generated (29% of the full package of 58MB).

[0155] The two update packages were distributed simultaneously, VSA was hot-loaded in parallel, and canary inferences were successfully verified (mean confidence scores of 0.83 and 0.79, respectively). Both models were successfully submitted to the new version. The overall end-cloud version collaboration took approximately 14 seconds, while the full replacement solution took approximately 78 seconds (saving 82% of update time).

[0156] In summary, the intelligent vehicle edge-cloud model version collaborative management system provided in this application embodiment has at least the following advantages:

[0157] First, by monitoring cloud-based basic model upgrades through cloud response, and based on a set depth limit, BFS technology is applied to traverse the version dependency graph to identify edge-side inference models that have version dependencies with the cloud-based basic model. This accurately tracks the edge-cloud model version dependency chain, triggering evaluation and updates only for edge-side models that truly have version dependencies, thereby reducing OTA bandwidth waste.

[0158] Second, the compatibility assessment results are obtained by performing a multi-dimensional compatibility assessment on the edge-side inference model. This multi-dimensional compatibility assessment includes interface compatibility assessment, accuracy compatibility assessment, and performance compatibility assessment, covering the three main failure modes of edge-cloud version inconsistency. Interface compatibility assessment mitigates runtime crashes caused by tensor shape / type mismatches, accuracy compatibility assessment mitigates inference accuracy degradation caused by feature space offsets, and performance compatibility assessment ensures that the model size does not exceed the onboard computing budget when expanded. This achieves a comprehensive and standardized adaptability assessment of the edge-side inference model and the upgraded cloud-based base model, improving the reliability of the inference service from the assessment stage.

[0159] Third, by dynamically selecting the minimum update strategy, OTA transmission volume and the number of writes to edge storage are reduced. Adaptation layer injection and incremental differential strategies only fix specific issues, reducing the resource waste of full replacement. The adaptation layer injection solution package size is less than 5MB, and the incremental differential solution package size is approximately 10%-30% of the full package size, saving 60%-90% of OTA transmission volume compared to full replacement, significantly reducing vehicle traffic costs and flash memory write losses. Based on the compatibility assessment results and the upgraded cloud-based basic model, an update package corresponding to the edge inference model is generated, ensuring that the update package content matches the actual adaptation requirements of the edge inference model. The update package is then pushed to the edge, improving the efficiency and accuracy of version updates, thereby ensuring the accuracy and efficiency of edge-cloud model version updates and providing update content support for the stable operation of the inference service.

[0160] Fourth, upon receiving the update packet via the edge response, candidate versions of the edge inference model are obtained based on the update packet. These candidate versions are then hot-loaded in parallel with their candidate states, and canary inference verification is performed based on them. This reduces the possibility of inference service interruption and ensures continuous availability of the inference service. Only when verification passes is the candidate version submitted as the active version, ensuring the compatibility and synergy between the edge inference model and the upgraded cloud-based base model. If verification fails, an automatic rollback occurs, uploading conflict information to the cloud and updating the version dependency graph. Within less than one second (memory-level version switching) after verification failure, the system reverts to the original stable version, reducing the inference failure rate caused by edge-cloud version incompatibility to near zero. This requires no manual intervention, meets the safety requirements of intelligent driving, and provides a basis for model version adaptation and dependency optimization.

[0161] Fifth, by diversifying the coverage of representative samples, the evaluation results are made more universal, reducing the probability of decision-making errors caused by environmental biases of a single vehicle. Differential privacy protection ensures data security, and the updated package is determined to be suitable for the entire fleet based on the aggregated distributed evaluation results, improving the reliability and security of large-scale fleet collaborative management. Closed-loop control of edge-cloud version collaborative management is achieved through version status feedback and graph updates. Dynamic updates to the version dependency graph in the cloud ensure accurate tracking of the impact range of subsequent upgrade events, improving the real-time nature and automation level of version management.

[0162] In summary, the intelligent vehicle edge-cloud model version collaborative management system provided in this application embodiment can realize automated collaborative management of edge-cloud model versions, and improve the reliability and stability of inference services.

[0163] Figure 5 This is a flowchart illustrating a collaborative management method for intelligent vehicle edge-cloud model versions provided in an embodiment of this application, applied to the cloud within the aforementioned collaborative management system for intelligent vehicle edge-cloud model versions. Figure 5 As shown, the intelligent vehicle edge-cloud model version collaborative management method includes:

[0164] S501: Upon detecting an upgrade of the cloud-based basic model, identify the edge-side inference model that has a version dependency relationship with the cloud-based basic model.

[0165] For example, the cloud continuously monitors the version iteration and upgrade status of the cloud base model in real time. After the cloud base model is detected to have completed the version upgrade and officially launched, the edge inference models that have a direct or indirect version dependency relationship with the cloud base model are identified. At the same time, edge inference models that have no version association, have completed version adaptation, or are offline are screened out.

[0166] S502. Obtain the compatibility evaluation results obtained by performing a multi-dimensional compatibility evaluation on the peer-side inference model. The multi-dimensional compatibility evaluation includes interface compatibility evaluation, accuracy compatibility evaluation, and performance compatibility evaluation.

[0167] For example, a multi-dimensional compatibility assessment is performed on the edge-side inference model, including interface compatibility assessment, accuracy compatibility assessment, and performance compatibility assessment, to determine whether the interaction interface, inference performance, and hardware capacity meet the requirements, thus obtaining the compatibility assessment result corresponding to the edge-side inference model. Optionally, the compatibility assessment result can also be obtained by performing a multi-dimensional compatibility assessment after the cloud-based basic model has been trained.

[0168] S503. Based on the compatibility assessment results and the upgraded cloud-based basic model, generate an update package corresponding to the edge inference model and push the update package to the edge. The edge is used to update the edge inference model according to the update package.

[0169] For example, based on the above compatibility assessment results, and considering the version characteristics, parameter specifications, interface definitions, and adaptation requirements of the upgraded cloud-based basic model, an update package matching the actual adaptation needs of the client-side inference model is generated. The content and form of the update package match the corresponding compatibility assessment results, ensuring compatibility between the client-side inference model and the upgraded cloud-based basic model. After the update package is generated, it is pushed to the client side via an OTA secure channel, ensuring the security and reliability of the update package transmission.

[0170] Figure 6 This is another flowchart illustrating the intelligent vehicle edge-cloud model version collaborative management method provided in this application embodiment, applied to the edge side of the aforementioned intelligent vehicle edge-cloud model version collaborative management system. For example... Figure 6 As shown, the intelligent vehicle edge-cloud model version collaborative management method includes:

[0171] S601. Receive the update package pushed from the cloud. The update package is obtained by the cloud executing the above-mentioned intelligent vehicle end-to-cloud model version collaborative management method.

[0172] It should be noted that after the device receives the update package obtained by the cloud through the above-mentioned intelligent vehicle end-to-cloud model version collaborative management method, it needs to verify the integrity and legality of the update package.

[0173] S602. Based on the update package, obtain candidate versions of the edge inference model.

[0174] For example, the client performs targeted parsing, fusion, loading, or initialization operations based on the type and core content of the update package, and performs targeted updates or fine-tuning on the client-side inference model based on different update package types and core content to obtain candidate versions of the client-side inference model.

[0175] S603. Candidate versions are hot-loaded in parallel with candidate states, and canary inference verification is performed based on the candidate versions to obtain the verification results corresponding to the candidate versions.

[0176] For example, the candidate version is hot-loaded in parallel in the background while in an inactive candidate state, enabling parallel operation of the candidate version loading and the original inference service. After the candidate version is hot-loaded in parallel, the canary inference verification process is executed, allocating an independent isolated inference verification environment for the candidate version and obtaining the verification results corresponding to the candidate version.

[0177] S604. If the verification result indicates that the verification is successful, the candidate version will be submitted as the active version of the edge inference model.

[0178] For example, if the verification result indicates that the verification passed, meaning that the candidate version is compatible with the collaborative operation requirements of the upgraded cloud-based basic model, then the candidate version is officially submitted as the new active version of the edge inference model. The entire version switching process is completed quickly in the background, without interrupting the currently executing inference task or causing significant service delays. Simultaneously, the original edge inference model is downgraded to a fallback version and stored locally on the edge as an emergency backup option.

[0179] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device 70 provided in this application embodiment includes at least one processor 701 and a memory 702. Optionally, the electronic device 70 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus.

[0180] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above-described method.

[0181] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0182] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0183] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0184] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0185] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0186] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0187] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0188] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0189] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0190] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0191] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0192] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0193] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0194] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A smart vehicle end-to-cloud model version collaborative management system, characterized in that, Including cloud and edge, among which: The cloud is used to respond to the detection of a cloud-based basic model upgrade, identify the edge inference model that has a version dependency relationship with the cloud-based basic model; obtain the compatibility assessment results obtained by performing a multi-dimensional compatibility assessment on the edge inference model, the multi-dimensional compatibility assessment including interface compatibility assessment, accuracy compatibility assessment and performance compatibility assessment; and generate an update package corresponding to the edge inference model based on the compatibility assessment results and the upgraded cloud-based basic model, and push the update package to the edge. The endpoint is configured to respond to receiving the update packet and update the endpoint inference model based on the update packet.

2. The intelligent vehicle edge-cloud model version collaborative management system according to claim 1, characterized in that, Includes at least one of the following: The interface compatibility assessment includes: comparing the input tensor specifications and / or output tensor specifications registered by the edge inference model with the interface declaration of the upgraded cloud base model; if the input tensor specifications are inconsistent with the interface declaration, or the output tensor specifications are inconsistent with the interface declaration, the interface is determined to be incompatible. The accuracy compatibility assessment includes: running the edge-side inference model and the upgraded back-end inference model on a pre-defined calibration dataset to obtain the accuracy degradation and relative entropy of the edge-side inference model and the upgraded back-end inference model, wherein the upgraded back-end inference model is generated based on the upgraded cloud-based basic model; if the accuracy degradation exceeds a preset degradation threshold or the relative entropy exceeds a preset relative entropy threshold, it is determined to be incompatible in terms of accuracy. The performance compatibility assessment includes: estimating the inference latency increment and video memory increment of the edge inference model on the target hardware based on the model structure performance of the upgraded cloud-based basic model; if the inference latency increment exceeds the latency increment limit or the video memory increment exceeds the video memory increment limit, it is determined to be performance incompatible.

3. The intelligent vehicle edge-cloud model version collaborative management system according to claim 1 or 2, characterized in that, When the cloud generates the update package corresponding to the edge inference model based on the compatibility assessment results and the upgraded cloud base model, it is specifically used for: Determine the minimum update strategy corresponding to the compatibility assessment results. The minimum update strategy is used to minimize the cloud-end transmission volume and / or minimize the number of writes to the end-side storage. Based on the minimum update strategy and the upgraded cloud-based basic model, an update package corresponding to the edge-side inference model is generated.

4. The intelligent vehicle edge-cloud model version collaborative management system according to claim 3, characterized in that, The step of determining the minimum update strategy corresponding to the compatibility assessment result includes: If the compatibility assessment result is that the interface is compatible, the accuracy is compatible, and the performance is compatible, then the minimum update strategy corresponding to the compatibility assessment result is determined to be the no-update strategy. If the compatibility assessment result is that the interface is incompatible, the accuracy is compatible, and the performance is compatible, then the minimum update strategy corresponding to the compatibility assessment result is determined to be the adaptation layer injection strategy. If the compatibility assessment result indicates incompatibility in accuracy but compatibility in performance, the minimum update strategy corresponding to the compatibility assessment result is determined to be the incremental parameter difference strategy. If the compatibility assessment result is performance incompatibility, the minimum update strategy corresponding to the compatibility assessment result is determined to be the full model replacement strategy. If the compatibility assessment result indicates that the interface is incompatible and the accuracy is incompatible, then the minimum update strategy corresponding to the compatibility assessment result is determined to be the full model replacement strategy.

5. The intelligent vehicle edge-cloud model version collaborative management system according to claim 1 or 2, characterized in that, The end side is specifically used for: Based on the update package, candidate versions of the edge-side inference model are obtained; The candidate versions are hot-loaded in parallel with the candidate states, and canary inference verification is performed based on the candidate versions to obtain the verification results corresponding to the candidate versions. If the verification result indicates that the verification is successful, the candidate version will be submitted as the active version.

6. The intelligent vehicle edge-cloud model version collaborative management system according to claim 5, characterized in that, The end side is also used for: If the verification result indicates that the verification fails, conflict information is reported to the cloud. The conflict information is used to indicate the version dependency relationship between the upgraded cloud base model and the edge inference model.

7. The intelligent vehicle edge-cloud model version collaborative management system according to claim 1 or 2, characterized in that, The intelligent vehicle edge-cloud model version collaborative management system includes multiple edge devices, and pushing the update package to the edge devices includes: Based on geographical location and / or hardware configuration, representative samples are extracted from the multiple terminal sides; The update package is pushed to the representative sample to obtain the verification result of the representative sample performing canary reasoning verification on the update package; By using differential privacy protection technology, the verification results corresponding to the representative samples are aggregated and distributed for evaluation to obtain aggregated distributed evaluation results. If the aggregated distributed evaluation results indicate that the verification is successful, the update package is pushed to non-representative samples among the multiple endpoints.

8. The intelligent vehicle edge-cloud model version collaborative management system according to claim 1 or 2, characterized in that, When determining an edge-side inference model that has a version dependency with the cloud-based base model, the cloud specifically uses the following: Based on the set depth limit, the breadth-first search technique is applied to traverse the version dependency graph to determine the edge inference models that have version dependencies with the cloud base model. The version dependency graph is used to reflect the direct and indirect dependencies between the edge inference models and the cloud base model. Correspondingly, the terminal side is also used to push the version confirmation information corresponding to the update package to the cloud when the terminal side inference model is successfully updated according to the update package; The cloud platform is also used to update the version number and status of the edge-side inference model in the version dependency graph based on the version confirmation information.

9. A method for collaborative management of intelligent vehicle end-to-cloud model versions, characterized in that, The intelligent vehicle edge-cloud model version collaborative management method, applied in the cloud-based intelligent vehicle edge-cloud model version collaborative management system as described in any one of claims 1 to 8, comprises: Upon detecting an upgrade of the cloud-based basic model, the endpoint inference model is identified as having a version dependency relationship with the cloud-based basic model. Obtain the compatibility evaluation results obtained by performing a multi-dimensional compatibility evaluation on the terminal inference model. The multi-dimensional compatibility evaluation includes interface compatibility evaluation, accuracy compatibility evaluation, and performance compatibility evaluation. Based on the compatibility assessment results and the upgraded cloud-based basic model, an update package corresponding to the edge inference model is generated, and the update package is pushed to the edge, which is used to update the edge inference model according to the update package.

10. A method for collaborative management of intelligent vehicle edge-cloud model versions, characterized in that, The intelligent vehicle edge-cloud model version collaborative management method, applied to the edge side of any one of claims 1 to 8, comprises: Receive update packages pushed from the cloud, wherein the update packages are obtained by the cloud executing the intelligent vehicle end-to-cloud model version collaborative management method as described in claim 9; Based on the update package, candidate versions of the edge-side inference model are obtained; The candidate versions are hot-loaded in parallel with the candidate states, and canary inference verification is performed based on the candidate versions to obtain the verification results corresponding to the candidate versions. If the verification result indicates that the verification is successful, the candidate version is submitted as the active version of the edge inference model.

Images