Automatic model synchronization and version control system and method for multi-model platform

Abstract

The invention provides an automatic model synchronization and version control system and method for a multi-model platform, and relates to the technical field of artificial intelligence model management, and the system comprises a model discovery module which detects a first type of model and a second type of model of a multi-model external platform; the model synchronization module comprises an influence evaluation sub-module, a synchronization sub-module and a mirror image synchronization sub-module, and is used for carrying out influence degree evaluation on the second type of models and executing model synchronization; the version control module is used for performing version difference comparison on the multi-model local platform and the multi-model external platform and performing unified processing on different version files with differences; and the multi-mechanism detection module is used for carrying out detection optimization processing on the models which are synchronously completed in the multi-model local platform. Through the method and the device, the technical problem of low model synchronization efficiency caused by dispersed interfaces of the multi-model platform in the prior art is solved, it is ensured that the multi-platform model file is accurately synchronized to the own platform, and the model synchronization efficiency and accuracy of the multi-model platform are improved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence model management technology, specifically to an automatic model synchronization and version control system and method for multi-model platforms. Background Technology

[0002] With the widespread application of large-scale model technology in production environments, model repositories have become a core component of AI infrastructure. However, significant differences exist among mainstream platforms in model organization, application programming interfaces (APIs), metadata formats, and version management mechanisms. This heterogeneity leads to fragmentation challenges in the unified management of cross-platform models. Enterprises often need to develop separate adaptation and synchronization tools for different platforms, making model discovery, retrieval, version tracking, and batch maintenance operations complex, difficult to automate, and costly to manage. Existing technologies typically rely on indiscriminate full or rule-based synchronization, resulting in a large amount of redundant data transmission and synchronization delays, leading to low overall efficiency in model synchronization. Due to the lack of automated version consistency verification and health check mechanisms, missing files or version inconsistencies are easily introduced during synchronization, seriously threatening the overall stability and service continuity of multi-model platforms.

[0003] In summary, existing technologies suffer from the technical problem of low model synchronization efficiency due to the dispersed interfaces of multiple model platforms, which in turn affects the overall stability of the multi-model platform. Summary of the Invention

[0004] The purpose of this application is to provide an automatic model synchronization and version control system and method for multi-model platforms, in order to solve the technical problem in the prior art that the low efficiency of model synchronization due to the dispersed interfaces of multi-model platforms, which in turn affects the overall stability of multi-model platforms.

[0005] To achieve the above objectives, this application provides an automatic model synchronization and version control system and method for multi-model platforms.

[0006] Firstly, this application provides an automatic model synchronization and version control system for multiple model platforms, comprising: a model discovery module for detecting first-type and second-type models on multiple external model platforms; a model synchronization module comprising an impact assessment submodule, a synchronization submodule, and a mirror synchronization submodule, wherein the impact assessment submodule is used to assess the impact of the second-type models, the synchronization submodule is used to perform model synchronization of the first-type models and synchronization of models in the second-type models with an impact less than a preset synchronization threshold, and the mirror synchronization submodule is used to perform synchronization of models in the second-type models with an impact greater than or equal to the preset synchronization threshold; a version control module for comparing version differences between the local multi-model platform and the external multi-model platform, and uniformly processing differing version files; and a multi-mechanism detection module for detecting and optimizing models that have been synchronized on the local multi-model platform.

[0007] Optionally, the model discovery module includes: an access interface unit, which includes multiple access interfaces and collects a set of model metadata from the external platform of the multi-model system based on the multiple access interfaces, wherein the model metadata is a fingerprint digest representing a model file; and a model partitioning unit, which compares the received set of model metadata with the set of model metadata from the local platform of the multi-model system to obtain a first type of model and a second type of model, wherein the first type of model is a newly added model obtained from the comparison, and the second type of model is a changed model obtained from the comparison.

[0008] Optionally, the impact assessment submodule includes: a change feature extraction unit, which is used to extract model change feature vectors from the metadata set of the second type of model corresponding to the second type of model, including the proportion of model parameter changes, the degree of model structure change, the change of model samples, and the magnitude of model performance changes; and an impact calculation unit, which includes a pre-constructed synchronous impact function, and uses the synchronous impact function to perform weighted calculation on the model change feature vectors to obtain the impact assessment result of the second type of model.

[0009] Optionally, the synchronization submodule is used to perform model synchronization of the first type of model, including creating an initial version identifier on the multi-model local platform and synchronizing the first type of model to the multi-model local platform by reading the first type of model metadata set of the first type of model.

[0010] Optionally, the mirror synchronization submodule is used to perform model synchronization of the second type of models with a value greater than or equal to the preset synchronization impact, including: a mirror construction submodule, which is used to construct a model mirror object, including a set of model files, model runtime environment information, model configuration parameters and interfaces, and model dependencies; an isolation synchronization submodule, which is used to synchronize the model mirror object to a local mirror storage area, the local mirror storage area being logically isolated from the model runtime area of ​​the multi-model local platform; a mirror runtime verification submodule, which runs the model mirror object and executes a multi-level mirror verification unit; and a marking submodule, which is used to mark the second type of models according to the multi-level mirror verification unit and send the marking result to the multi-model local platform; wherein, the marking is used to establish an association between the marked second type of models and the second type of historical version models of the multi-model local platform.

[0011] Optionally, the multi-level image verification unit of the image operation verification submodule includes an image-level model consistency verification subunit and an image-level model function verification subunit; the image-level model consistency verification subunit includes model file hash consistency verification, runtime environment version matching verification, and configuration parameter integrity verification; the image-level model function verification subunit includes interface function callability verification and training function integrity verification.

[0012] Optionally, the multi-level mirror verification unit of the mirror run verification submodule further includes a model association verification subunit, which includes: an association relationship parsing channel, used to parse model association relationships and construct a model association graph based on the switching marker results, and extract multiple associated model subsets from the model association graph; an associated mirror run channel, used to generate mirror run combinations for each associated model subset in the multiple associated model subsets, and perform joint run tests based on the mirror run combinations to obtain a joint impact index; the marker submodule is used to jointly switch marker the mirror run combinations that are less than a preset joint impact threshold, wherein the joint switch marker is used to establish a joint association relationship with the second type of historical version model of the multi-model local platform.

[0013] Optionally, the marking submodule is used to switch the marking of the second type of model that passes the multi-level image verification unit, and to feed back the second type of model that does not pass the multi-level image verification unit to the image running verification submodule; the image running verification submodule is used to run the reconstructed model image object until it passes the multi-level image verification unit.

[0014] Optionally, the multi-mechanism detection module includes at least an availability detection mechanism, a hot update mechanism, and an error tolerance mechanism.

[0015] Secondly, this application also provides an automatic model synchronization and version control method for multi-model platforms. The method includes: detecting a first type of model and a second type of model on a multi-model external platform; evaluating the impact of the second type of model; performing model synchronization for the first type of model and for models in the second type of model with an impact less than a preset synchronization threshold; performing model synchronization for models in the second type of model with an impact greater than or equal to the preset synchronization threshold; comparing version differences between the multi-model local platform and the multi-model external platform; uniformly processing differing version files; and detecting and optimizing the synchronized models on the multi-model local platform.

[0016] One or more technical solutions provided in this application have at least the following technical effects or advantages: Real-time monitoring and classification of models on a multi-model platform are achieved through a model discovery module; a reinforcement learning mechanism is introduced into the impact assessment submodule to dynamically optimize the assessment strategy for model synchronization impact; a differentiated synchronization strategy for models with different impact levels is achieved by combining the synchronization submodule and the mirror synchronization submodule; model consistency and accuracy are ensured through version difference comparison and processing; a multi-mechanism detection module is introduced to optimize the synchronized model; and reinforcement learning is used for continuous tuning and hot update strategies to ensure accurate synchronization of multi-platform model files to the proprietary platform, thereby improving the efficiency and accuracy of multi-model platform model synchronization and further enhancing the overall stability of the multi-model platform.

[0017] The above description is merely an overview of the technical solution of this application. To better understand the technical means of this application and to facilitate its implementation according to the description, and to make the above and other objects, features, and advantages of this application more apparent, specific embodiments of this application are described below. It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent through the following description. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely exemplary. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1This is a schematic diagram of the structure of the automatic model synchronization and version control system for multi-model platforms in this application.

[0020] Figure 2 This is a flowchart illustrating the automatic model synchronization and version control method for multi-model platforms proposed in this application.

[0021] Figure labeling: Model discovery module 11, Model synchronization module 12, Version control module 13, Multi-mechanism detection module 14. Detailed Implementation

[0022] This application provides an automatic model synchronization and version control system and method for multi-model platforms, solving the technical problem in existing technologies where the dispersed interfaces of multiple model platforms lead to low model synchronization efficiency, thus affecting the overall stability of the multi-model platform. The system utilizes a model discovery module to monitor and classify models on multiple model platforms in real time. An impact assessment submodule introduces a reinforcement learning mechanism to dynamically optimize the assessment strategy for model synchronization impact. Combined with synchronization and mirror synchronization submodules, differentiated synchronization strategies are implemented for models with different impact levels. Version difference comparison and processing ensure model consistency and accuracy. A multi-mechanism detection module optimizes synchronized models, and reinforcement learning is used for continuous tuning and hot-update strategies to ensure accurate synchronization of model files from multiple platforms to the proprietary platform. This improves the efficiency and accuracy of model synchronization across multiple model platforms, further enhancing the overall stability of the multi-model platform.

[0023] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. It should be understood that this application is not limited to the exemplary embodiments described herein. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application. It should also be noted that, for ease of description, only the parts related to this application are shown in the accompanying drawings, not all of them.

[0024] Example 1, please refer to the appendix. Figure 1 This application provides an automatic model synchronization and version control system for multi-model platforms. The automatic model synchronization and version control system for multi-model platforms is used to implement the steps of an automatic model synchronization and version control method for multi-model platforms. The automatic model synchronization and version control system for multi-model platforms includes: Model discovery module 11 is used to detect the first type of model and the second type of model on a multi-model external platform.

[0025] Furthermore, the model discovery module 11 in the automatic model synchronization and version control system for multi-model platforms is also used for: an access interface unit, which includes multiple access interfaces, and collects the model metadata set of the external platform of the multi-model system based on the multiple access interfaces, wherein the model metadata is a fingerprint digest representing the model file; and a model partitioning unit, which compares the received model metadata set with the model metadata set of the local platform of the multi-model system to obtain a first type of model and a second type of model, wherein the first type of model is a newly added model obtained by comparison, and the second type of model is a changed model obtained by comparison.

[0026] Specifically, the model discovery module is an automated component whose core responsibility is to proactively scan and identify available models on specified external model platforms and compare them with existing local models to discover newly added or modified model resources. It is first initiated by the access interface unit, which has pre-built connectors for different external platforms. When a discovery task is triggered, these connectors work in parallel, each calling the API of its corresponding platform. However, instead of downloading large model files, they efficiently obtain a lightweight list of models and their core identifying information, such as model ID and version number.

[0027] The Access Interface Unit (AUI) is responsible for communicating with the outside world. It's not a single interface, but rather a collection of adapters. Each adapter is designed with an API or data format for connecting to and parsing a specific external model platform. The core function of the AUI is data collection—that is, acquiring basic information about models on the platform in batches by calling their public interfaces. For example, for an open-source model platform, the AUI executes multiple tasks in parallel: calling the `list_models(author=org)` interface to retrieve all models from that organization; calling the interface with filtering parameters to retrieve the model with the highest download volume for the text classification task; and simultaneously, a lightweight crawler thread accesses the Trending page to retrieve the list of the most popular models in the community that day. When monitoring detects a new model or model update, the new model is immediately added to the synchronization queue and marked as the highest priority, to be completed within 0 days. Then, the immediate synchronization process is triggered to ensure that models from important organizations can be synchronized to the local platform as soon as possible.

[0028] The first type of model is a newly added model discovered from an external platform that does not yet exist in the local multi-model platform; the second type of model is a model that already exists on the local platform, but has undergone some changes on the external platform, such as updates, fine-tuning, or other modifications.

[0029] The model metadata set is a list of key information describing the model; it's not the model file itself, but rather its identity card. A fingerprint digest is data that uniquely and compactly represents the entire content of the model file, used to uniquely identify a file. It's typically a long, fixed-length string calculated using a cryptographic hash algorithm, called a hash value. Any tiny file modification will cause a drastic change in the hash value, making it an ideal fingerprint for verifying file consistency.

[0030] The model metadata set collected from the multi-model external platform is compared with the model metadata set from the multi-model local platform. This is done through hash value comparison. A fingerprint digest of each model file is calculated and then matched, classifying the comparison results into two categories: Category 1 and Category 2 models. The model partitioning unit is used to compare the model metadata sets from the multi-model external platform and the multi-model local platform to identify which models are new and which have changed. Metadata comparison compares the model metadata obtained from the external platform with the existing metadata on the local platform, identifying new or changed models through hash value calculation and other methods. A hash value is a fixed-length string generated by a hash algorithm to represent the uniqueness of the original data. For each file, the file content can be converted into a unique hash value using a hash algorithm. Even a small change in the file content will result in a significant change in the hash value, thus ensuring the integrity and uniqueness of the file. The specific process is as follows: Model files from the multi-model external platform and the multi-model local platform are collected. Each model file consists of multiple parts, such as configuration files and weight files. Each model file is hashed individually, using a hash algorithm like SHA-256. The content of each file is passed to the SHA-256 algorithm, which outputs a fixed-length 64-character hash value. For example, suppose the hash value of a model file is abc123def456. Each file's hash value serves as its fingerprint digest. For a complete model, there are multiple files, and the hash value of each file is calculated. The algorithm retrieves a set of hash values ​​for model files from an external platform, corresponding to the model files on that platform. It also retrieves a set of hash values ​​for local model files from the local platform. If a file on the external platform has a hash value that cannot be found in the local platform's hash value set, it is considered a newly added model (Category 1), a new file that does not yet exist on the local platform. If a file on the external platform has the same hash value as a file on the local platform, but other metadata or version numbers have changed, it is considered a modified model (Category 2). For example, suppose the fingerprint digest of a model on the external platform is abcdef1234567890, and a model with the same fingerprint digest already exists on the local platform. However, the version number of the external platform for the multi-model is v2.0, while the version number of the local platform for the multi-model is v1.0. Therefore, this model is identified as a modified model (type II model).

[0031] In other words, the model partitioning unit loads the local fingerprint directory of all currently managed models from local storage. It first performs a fast search, matching each fingerprint in the external directory against the local directory. Models that match exactly are marked as unchanged and ignored. For entries whose fingerprints are not found in the local directory, the engine performs a second check: if it's a completely new model ID, it's classified as a first-class model; if it's an existing model ID but with a different fingerprint, it means a new version of the same model has been released, and it's classified as a second-class model. The first-class and second-class models are output, representing the list of new models to be introduced and the list of existing models to be updated.

[0032] The model discovery module significantly improves the automation level of cross-platform model resource management, automatically identifying new and modified models and reducing the workload of manual inspection and operation. Through precise metadata comparison, it ensures model version consistency and integrity, avoiding model version conflicts or loss.

[0033] The model synchronization module 12 includes an impact assessment submodule, a synchronization submodule, and a mirror synchronization submodule. The impact assessment submodule is used to assess the impact of the second type of model. The synchronization submodule is used to perform model synchronization of the first type of model and model synchronization of the second type of model with an impact less than a preset synchronization value. The mirror synchronization submodule is used to perform model synchronization of the second type of model with an impact greater than or equal to the preset synchronization value.

[0034] Furthermore, the model synchronization module 12 in the automatic model synchronization and version control system for multi-model platforms is also used for: the impact assessment submodule includes: a change feature extraction unit, which is used to extract model change feature vectors from the metadata set of the second type of model corresponding to the second type of model, including the proportion of model parameter changes, the degree of model structure change, the change of model samples, and the magnitude of model performance changes; and an impact calculation unit, which includes a pre-constructed synchronization impact function, and uses the synchronization impact function to perform weighted calculation on the model change feature vectors to obtain the impact assessment result of the second type of model.

[0035] Specifically, the model synchronization module is responsible for the unified management of cross-platform model resources, including the impact assessment submodule, the synchronization submodule, and the mirror synchronization submodule. The impact assessment submodule is specifically used to handle the second type of model. By analyzing the differences between the new version of the model and the local old version, it quantifies the degree of impact that this change may have on downstream businesses and outputs an impact score.

[0036] The change feature extraction unit of the impact assessment submodule extracts change features from the metadata of the second type of model to analyze the specific circumstances of model changes. The impact degree calculation unit calculates the impact degree based on the extracted change feature vector using a pre-built synchronous impact degree function, and finally obtains the impact assessment result of the model.

[0037] When a task for a second-type model is received, the feature extraction unit is activated first. Simultaneously, it acquires the latest metadata of the model on the external multi-model platform and the historical version metadata stored on the local multi-model platform for differential detection. Regarding the proportion of model parameter changes, a file comparison algorithm prioritizes comparing the hash values ​​of the model weight files. If the root hashes differ, a lower-level binary differential analysis is performed to accurately calculate the proportion of changed data blocks, avoiding misjudgments caused by file repackaging. Simultaneously, regarding the degree of model structural change, both the old and new files are parsed, and dozens of key configuration items are extracted and compared one by one. A pre-defined structural change scoring table is used; for example, doubling the hidden_size might score 0.8 points, adding a decoder layer 0.5 points, and these scores are ultimately normalized to a comprehensive structural change degree between 0 and 1. For model sample changes, natural language processing techniques are used to extract keywords and perform semantic analysis on the model repository's commit logs and version descriptions, identifying key expressions and converting them into a confidence score between 0 and 1. Finally, regarding the magnitude of model performance changes, we attempt to retrieve the evaluation results on authoritative datasets from the standardized fields of the model cards. If the data is complete, we directly calculate the relative percentage change; if missing, the feature value may be temporarily set to unknown and handled specially by the subsequent weighting function. In the internal data structure, the status bit of the feature is set to UNKNOWN, and the reason for the missing value is recorded. The original weights of the feature are temporarily stored. The computation unit will proportionally redistribute these weights to other known and reliable features using a proportional allocation method. Assuming the original weights are W1=0.50, W2=0.30, W3=0.15, and W4=0.05, where the state of V4 is UNKNOWN, the sum of the original weights of all features in non-UNKNOWN states is 0.95, and the original weight of UNKNOWN features is 0.05, then the adjusted weights are W1=0.5+(0.5 / 0.95)*0.05=0.526, W2=0.316, W3=0.158, and W4=0. Using the adjusted weights W1, W2, and W3 with the known feature values, a standard weighted calculation is performed to obtain a preliminary influence score. After the model parameter change ratio, model structure change degree, model sample change, and model performance change magnitude are extracted and standardized, they are encapsulated into a four-dimensional model change feature vector and immediately sent to the influence calculation unit.

[0038] For example, in a specific impact assessment of upgrading the image generation model XL from version v1.0 to v1.1, the feature extraction unit was changed as follows: By comparing the core weight files base1.0.safetensors (approximately 6.9GB) and base1.1.safetensors (approximately 6.9GB) of the two versions, using block-level hash comparison, it was found that approximately 1.2GB of data block content had changed. The calculated parameter change ratio was approximately 17.4%. Analyzing the configuration files of the two versions, it was found that the main U-Net structure of the model remained unchanged, but the cross_attention_dim parameter was adjusted from 1280 to 2048, and a configuration reference for the Refiner module was added. According to the preset scoring rules, the structural change was evaluated as 0.4, with 0 indicating no change and 1 indicating complete reconstruction. Analyzing the model release notes, it was clearly mentioned that in v1.1, a more aesthetically vetted expanded dataset was used for fine-tuning. The Natural Language Processing module recognized this description as a substantial improvement in training data quality, rather than a complete replacement of the dataset, therefore the confidence score for the sample change was set at 0.7. Data was extracted from the official benchmark results. The new version improved by 5% in prompt word following accuracy and 8% in image aesthetics score, but decreased by 3% in generation speed. The weighted average of the changes in the three metrics was calculated, resulting in an overall performance change of +3.3%. Thus, the feature vector [0.174, 0.4, 0.7, 0.033] was generated.

[0039] The impact calculation unit includes a pre-built synchronous impact function. Its input is the model change feature vector, and its output is a scalar value representing the overall impact, such as a score from 0 to 100. The core of this function is a set of weights, each corresponding to a dimension of the feature vector, representing the importance of that dimension's feature to the overall risk. The function form is typically a weighted sum of the feature values, but it could also be a more complex nonlinear function.

[0040] The input normalization layer of the pre-constructed synchronization influence function receives the original feature vectors from the feature extraction unit. Since the dimensions and ranges of each feature value differ (e.g., parameter change ratio is a percentage, structural change is a 0-1 score, and performance change might be a percentage point), direct weighted calculation would lead to features with larger dimensions dominating the result. Therefore, this layer performs max-min normalization on each feature, mapping it to the [0,1] interval, using existing technology. The second layer is the weighted calculation core layer, whose core is the pre-constructed synchronization influence function, which uses a linear weighted sum form: Synchronization Influence = w1 × Model Parameter Change Ratio + w2 × Model Structural Change + w3 × Model Sample Change + w4 × Model Performance Change Amplitude + b, where w1, w2, w3, and w4 are the importance weights of each feature, and b is the bias term. Collect at least 500 historical synchronization records, each containing the original values ​​of four features and an impact score of 0-100, labeled by experts based on the actual impact after synchronization. Divide the dataset into training and validation sets in a 7:3 ratio. Use the least squares method to solve for the optimal weights. The loss function uses mean squared error and incorporates an L2 regularization term to prevent overfitting. Cross-validation ensures that the model's coefficient of determination R² is greater than 0.85 and the recall rate of high-risk samples exceeds 90%. After training, determine the weight and bias values, such as configuring the weights as [0.48, 0.31, 0.16, 0.05] and the bias as 0.03. The third layer is the output mapping and decision layer, which maps the weighted synchronization impact to the standard impact score of [0, 100] through linear scaling and generates synchronization decisions based on preset thresholds. This layer also outputs a detailed contribution of each feature, forming an interpretable evaluation report. Input features directly correspond to business risks; for example, parameter changes exceeding 30% may affect inference stability, and structural changes greater than 0.5 often require adjustments to client-side code. Output scores directly drive synchronization strategies: low-risk scenarios trigger incremental synchronization, while high-risk scenarios force entry into mirror synchronization. The impact calculation unit periodically and automatically recalibrates weights using newly added data to ensure the evaluation model continuously adapts to ecosystem changes.

[0041] In actual operation, some feature data relied upon for impact assessment, such as the magnitude of model performance changes, may be temporarily missing due to reasons such as the source platform not providing them or temporary test environment failures. To ensure the robustness of the assessment process, i.e., uninterrupted operation, and to avoid misjudgments due to incomplete data, a fault-tolerant handling mechanism for missing features was designed. This is not an arbitrary modification of the core assessment model, but an extension based on several rigorous principles, including: the principle of logical consistency, where the handling method must be compatible with the internal logic of the complete assessment model; the principle of risk conservatism, where the uncertainty of the assessment results must be reflected in subsequent decisions and a preference for safer paths; and the principle of transparency and traceability, where all adjustments are clearly recorded to ensure auditability. When a feature data point is missing, it is not replaced with zero or a default value, but rather a structured weight rebalancing operation is performed. The original weights of the missing feature are dynamically redistributed to them according to the relative importance ratios of other known features in the original model, ensuring that the influence weight relationship of known features on the final score remains consistent with the relationship established during the training of the complete model, even when some information is unknown. Simultaneously, the parameters used for input standardization are pre-calculated and stored based on complete historical data during the model training phase. For each known feature, it is standardized using its own fixed parameters. This process is completely unaffected by the absence of other features, ensuring that the feature values ​​input to the computational core are always within the range expected during model training. A clear confidence rating (high, medium, low) is generated for each evaluation, directly reflecting the completeness of the information used in the evaluation. This rating, along with the calculated score, is input into the downstream synchronous decision-making module. The decision logic adapts accordingly: for models with high scores and low confidence, the most conservative strategy is automatically adopted, such as forcing them into a mirrored synchronous safe path requiring isolation and verification. This means that the uncertainty introduced by missing data is systematically transformed into a higher level of vigilance against potential risks. While this may slightly increase the verification cost of some synchronous tasks, it is a cost to prevent unknown defects from impacting the production environment. From a global perspective, by automatically increasing the safety level when information is incomplete, the core effects of ensuring model consistency and optimizing resource allocation are reliably achieved even in complex real-world environments, making it a key element in improving the overall stability of the platform.

[0042] By quantifying various changes to the model, the impact of model changes is accurately assessed, avoiding blind synchronization and inefficient updates. The impact calculation module determines which model changes require high priority processing, thereby improving the efficiency and accuracy of model synchronization. Synchronization decisions based on impact can prioritize the allocation of resources to model updates with greater impact, thus reducing system downtime and optimizing the synchronization process. The impact assessment mechanism ensures timely system response to critical model changes, avoiding wasted computing resources on low-impact model updates.

[0043] Furthermore, the model synchronization module 12 in the automatic model synchronization and version control system for multi-model platforms is also used for: the synchronization submodule is used to perform model synchronization of the first type of model, including creating an initial version identifier on the multi-model local platform, and synchronizing the first type of model to the multi-model local platform by reading the first type of model metadata set of the first type of model.

[0044] Specifically, all Category 1 models, being newly introduced and without historical burden, are automatically assigned to the synchronization submodule for regular synchronization. For Category 2 models, their impact score is compared to a preset synchronization impact threshold. Models with a score below the threshold are considered low-risk updates (e.g., those fixing only a boundary condition bug) and are directly synchronized to the production repository by the synchronization submodule. Models with a score above the threshold are identified as high-risk updates and routed to the mirror synchronization submodule. In short, the synchronization submodule is responsible for performing regular, low-risk synchronization operations, handling two types of tasks: initial synchronization of all new models and update synchronization of low-risk changed models.

[0045] From the metadata and file information of the old and new versions of the second type of model to be evaluated, the change features of four core dimensions are extracted and quantified to form the original feature vector. The proportion of model parameter changes, the degree of model structure change, the changes in model samples, and the magnitude of model performance changes are then calculated. Since the four features have different dimensions and value ranges, they need to be normalized to map them to a uniform scale, such as 0-1, for weighted calculation. The result is calculated using the aforementioned formula for the degree of synchronous influence.

[0046] In the model registry or metadata database of the multi-model local platform, a unique registration entry is created for the model. A key operation is assigning an initial version identifier, binding it to the model ID, as the starting point for the model's local lifecycle management. Simultaneously, metadata obtained from external multi-model platforms is written to this entry. The initial version identifier is a unique and initial version tag created for the first type of model when it is synchronized to the local platform for the first time. It is typically not a simple integer, but a composite identifier combining the source platform's original version number, synchronization timestamp, and synchronization task ID, used to uniquely identify a specific instance of the model within the local platform and establish a traceability relationship with the source. First, the source platform's inherent version identifier, such as the tag v2.0, is read from the metadata set, generating a high-precision timestamp and a unique serial number for this synchronization task. These elements are concatenated and hashed with the model ID to form the final initial version identifier, such as llama-3-8b_external-main_hash-a1b2c3d4. This is written to the local platform's metadata database, registering the model as a new asset entry and marking its status as synchronizing.

[0047] Based on the blueprint in the metadata set, the core file transfer process of full synchronization is initiated. The crucial model storage path information from the metadata is read, typically a downloadable URL. A network request is then initiated to download all entity files of the model completely to the local platform's specified storage system with a version directory structure. For example, the v1.0.0 version file of the model bert-base-uncased will be downloaded to a directory like / model_repo / bert-base-uncased / v1.0.0 / , ensuring the binary integrity of the files. After downloading, the file's hash value is usually calculated and verified against the fingerprint digest in the metadata to ensure error-free transmission.

[0048] The full synchronization process is as follows: The model's metadata set, including configuration files, training parameters, and model weight files, is obtained through the access interface unit. These files and their associated configuration information are then downloaded to the local storage area. For larger model files, such as deep learning models exceeding 2GB, parallel downloading can be used to accelerate synchronization, employing techniques such as large file storage. During synchronization, model information on the local platform is updated in real time, and the synchronization status is recorded to ensure that each model file is accurately synchronized to the designated location. Once synchronization is complete, a corresponding version identifier is generated and updated for the model to ensure consistency between the model on the local platform and the external platform.

[0049] After successful file synchronization and verification, the module updates the entry status of the model in the local registry, marking the status as synchronized and available, and recording the local storage path of the file. Simultaneously, a lightweight post-processing action is triggered, such as notifying the model's index service to update, enabling the new model to be discovered and loaded by the platform's model service layer. The entire process is designed to be transactional; any failure in any step, such as network download interruption, insufficient storage space, or hash verification failure, will roll back previously executed operations, such as deleting some files or removing registration entries, ensuring system consistency and reporting clear error messages for troubleshooting.

[0050] The first type of model metadata set is a descriptive information collection about the newly added model, gathered by the access interface unit from multiple external platforms. It includes not only fingerprint summaries for comparison but also key information such as model name, framework type, file size, storage path, required runtime environment, and a brief description. It serves as a task list for performing synchronization operations. Full synchronization refers to the process of transferring and storing the complete entity files of the model from the current external platform to the local platform's model repository in one go. In contrast to incremental synchronization, since it is the first time the model is introduced and there are no local base files, a full transfer is necessary.

[0051] After all files have been transferred and verified to be correct, the module performs the final database entry operation, moving all files from the temporary workspace to the permanent storage location according to the local platform's storage specifications. It updates the model asset status in the database to "synchronization successful" and associates a detailed synchronization report, including file list, size, hash, and time taken, with the data to the asset record. An event is triggered, notifying the availability check module to immediately perform a basic health check on the newly synchronized model. At this point, the entire process of a first-class model from discovery to its deployment and usability on the local platform is complete. This full synchronization mechanism ensures that newly added first-class models can be quickly and completely synchronized to the local platform, avoiding data loss or incomplete synchronization.

[0052] Furthermore, the model synchronization module 12 in the automatic model synchronization and version control system for multi-model platforms is also used for: the mirror synchronization submodule is used to perform model synchronization of the second type of models that is greater than or equal to the preset synchronization impact, including: a mirror construction submodule, which is used to construct a model mirror object, including a set of model files, model runtime environment information, model configuration parameters and interfaces, and model dependencies; an isolation synchronization submodule, which is used to synchronize the model mirror object to a local mirror storage area, the local mirror storage area being logically isolated from the model runtime area of ​​the multi-model local platform; a mirror runtime verification submodule, which runs the model mirror object and executes a multi-level mirror verification unit; and a marking submodule, which is used to mark the second type of models according to the multi-level mirror verification unit and send the marking result to the multi-model local platform; wherein, the marking is used to establish the association between the marked second type of models and the second type of historical version models of the multi-model local platform.

[0053] Specifically, the mirror synchronization submodule is responsible for handling the synchronization operation unit for high-risk model changes. It is triggered when the impact assessment of the second type of model reaches or exceeds the preset synchronization impact threshold. The preset synchronization impact threshold is a predefined quantitative risk threshold. When the impact assessment score of a model change reaches or exceeds this value, it is judged as a high-risk change and must enter the mirror synchronization process. This threshold can be dynamically adjusted according to business sensitivity.

[0054] The image building submodule operates within a dedicated build sandbox, a temporary computing environment isolated from the production network. First, based on the model's metadata, it pulls all model files for the new version from the source platform, including weight files, configuration files, tokenizers, etc., ensuring the file hashes match the source. Then, it automatically analyzes the model's runtime dependencies, not only downloading the new set of model files but also automatically analyzing or obtaining the precise runtime environment required, recording its service configuration parameters and API definitions, and scanning its code dependencies. All these elements are packaged into a single, independently deployable and runnable model image object, ensuring reproducible behavior in any consistent environment. The model image object, a standardized deliverable created by the image building submodule, is a complete compatible container image containing not only the model weight files, configuration files, and other model files, but also model runtime environment information, model configuration parameters and interfaces, and model dependencies. The entire build process is meticulously logged, and the generated image hash is recorded, ensuring the reproducibility of the build process.

[0055] The isolation synchronization submodule then takes over, creating a temporary, access-controlled subdirectory or bucket in the local image storage area for this synchronization task. The model image object is transferred from the build sandbox to this location via a secure internal network channel. The local image storage area and the model runtime area are logically isolated: they use different network CIDR blocks, different storage backends, and even different authentication systems. This means that any operation in the verification environment, including potential malicious code or resource leaks, cannot directly access or affect the production instance serving user requests. After synchronization is complete, the module creates a temporary workspace in the isolated verification cluster, using the newly pushed image to start one or more model service instances to prepare for verification. The isolation synchronization submodule is responsible for transferring and deploying the built model image object to a dedicated area logically isolated from the production environment. This area has resources similar to but completely independent of the production environment, ensuring that verification activities do not consume production resources or cause cascading failures, avoiding direct impact on the existing model runtime state of the local platform.

[0056] The image runtime verification submodule begins executing multi-level image verification units on the new version instance running in the isolated environment. Verification is layered and progressive. First, basic availability verification is performed, checking the container's health, service port listening, and resource mounting for proper functioning. Next, consistency verification is performed, recalculating the hash values ​​of critical files within the container to ensure consistency with those recorded during the build process, and verifying the runtime environment version matches the declaration. Then, functional correctness verification is performed, using pre-defined test case sets to infer the output format, content rationality, and performance baseline against expectations by calling the model's standard interfaces. For models that support training, training process verification may also be performed, running a simplified training cycle to check backpropagation and parameter update capabilities. Each verification level has clear pass / fail criteria and timeout controls; failure at any level will halt the process and log detailed information. Only when all verifications pass is the image considered to meet the deployment standards in terms of functionality and behavior.

[0057] The tagging submodule makes the final decision and generates a switchover tag based on the verification results. If all verifications pass, the module creates a verified record for this new version model in the platform's core metadata database, generating a structured switchover tag. This tag contains key information: the complete locator of the new version image, a verification report summary, a recommended switchover time window, and most importantly, its association with the corresponding second-type historical version model in the multi-model local platform. It clearly records which existing old version the new version is intended to replace and may include a summary of differences between versions. After this tag is generated, it is sent to the scheduling and control center of the multi-model local platform. Upon receiving the tag, the platform does not immediately execute the replacement but stores it as a pending release plan and updates the model asset catalog to make the new version visible to operations personnel. Only when the administrator confirms or when a preset automation policy is triggered will the hot update module perform a smooth traffic switchover during off-peak hours based on the associations and information in this tag. If verification fails, the tagging submodule generates a failure tag with detailed error diagnosis and triggers an alarm to notify relevant personnel, while automatically cleaning up relevant resources in the isolated environment.

[0058] Based on the verification results, the tagging submodule generates a clear instruction, a switch tag, which not only includes a pass or rejection conclusion, but more importantly, formally establishes the association and switch path between the high-risk new version model and the old version currently running stably in production. The switch tag indicates which new version model has been verified and is ready to replace which specific old version model in the production environment, and under what conditions or when the replacement will be performed. It is a formal work order connecting the verification environment and the production environment, containing a tag with the mapping relationship between the new and old versions. It is sent as a formal release instruction to the release coordinator or configuration management system of the multi-model local platform, awaiting final execution authorization. Through a logically isolated sandbox environment, all high-risk operations are strictly restricted, forming a firewall against changes to the production environment, achieving zero interruption and zero interference to production services during the change process.

[0059] Furthermore, the model synchronization module 12 in the automatic model synchronization and version control system for multi-model platforms is also used for: the multi-level mirror verification unit of the mirror operation verification submodule includes a mirror-level model consistency verification subunit and a mirror-level model function verification subunit; the mirror-level model consistency verification subunit includes model file hash consistency verification, runtime environment version matching verification and configuration parameter integrity verification, and the mirror-level model function verification subunit includes interface function callability verification and training function integrity verification.

[0060] Specifically, the multi-level image verification unit ensures the quality and reliability of the image model through a multi-level verification mechanism. This includes an image-level model consistency verification subunit and an image-level model functional verification subunit, employing a layered and progressive verification strategy. From the bottom-level consistency verification to the upper-level functional verification, it progressively ensures the reliability and correctness of the model image. The image-level model consistency verification subunit focuses on verifying the accuracy and completeness of the model image construction, ensuring that the model files, runtime environment, and configuration parameters in the image are consistent with expectations. This includes model file hash consistency verification, runtime environment version matching verification, and configuration parameter integrity verification. Model file hash consistency verification calculates the hash value of the model files in the image and compares it with the hash of the original files obtained from the source platform to ensure that the files have not been damaged or tampered with during transmission and construction. Runtime environment version matching verification checks whether the versions of the software packages installed in the image are consistent with the required versions of the model, avoiding abnormal model operation due to environmental differences. Configuration parameter integrity verification verifies whether the key parameters in the model configuration file are complete and match the model version, ensuring the correct model structure.

[0061] The verification process iterates through the storage paths of model files in the image, calculating the hash value of each file using a predefined hash algorithm. Simultaneously, it retrieves a list of hash values ​​for the corresponding files on the source platform from the metadata accompanying the synchronization task. These hash values ​​are compared one by one; if all file hash values ​​match exactly, the verification passes; otherwise, the information of the mismatched files is immediately recorded, the verification process terminates, and the file is marked as a consistency check failure. The verification process executes a series of shell commands to obtain the actual versions of key software in the image. Then, it compares these versions with the environment requirements recorded in the model metadata. Some flexibility is allowed for minor versions, but the major versions must be consistent. For example, if PyTorch 1.13.x is required, the actual version can be 1.13.0 or 1.13.1, but not 1.12.0 or 2.0.0. The verification process reads the model configuration files in the image and parses out all configuration items. Then, it compares these items with a predefined "list of necessary parameters." This list typically includes key parameters such as the model architecture name, hidden layer size, and number of attention heads. Simultaneously, the system checks the configuration file for obvious parameter errors, such as negative values ​​or abnormally large values. Furthermore, if the model has a corresponding architecture class, it attempts to initialize a model structure using the configuration without loading weights to ensure the configuration can be correctly parsed. Only after all three checks pass will the system proceed to the second stage. Failure in any one of these checks will generate a detailed error report, mark the verification as failed, and trigger an alert to notify the administrator.

[0062] The mirror-level model functionality verification subunit, after passing consistency verification, further verifies whether the model's actual functionality is normal. This includes interface functionality callability verification and training functionality integrity verification. Interface functionality callability verification simulates real-world usage scenarios, calling the application programming interface (API) exposed by the model mirror to verify whether the interface can respond normally, whether the input / output format conforms to the convention, and whether the error handling mechanism is robust. For models that support continued training or fine-tuning, training functionality integrity verification verifies whether its complete training pipeline runs normally, including key steps such as data loading, forward propagation, loss calculation, backpropagation, parameter updates, and checkpoint saving.

[0063] The API functionality verification simulates a real client sending test requests to the model service interface. First, the program confirms the reachability of the service endpoint, typically through an HTTP health check. The program selects a representative set of test cases from a pre-defined test case library, usually containing 3-5 simple cases and 2-3 boundary cases, constructing a request body that conforms to the interface specification. For example, for a text generation model, the request body might include: why the prompt word is "artificial intelligence," and the maximum number of generated tags is 50; for an image classification model, it might include base64 encoded test images. The verification program sends these requests and verifies the responses: checking if the HTTP status code is 200 (success), whether the response time is within acceptable limits (e.g., at least 95% of requests should have a response time <500ms), and whether the response body format conforms to the API documentation. Furthermore, the program tests error handling capabilities by intentionally sending requests with incorrect formats or out-of-bounds parameters to verify whether the service can return appropriate error codes and clear error messages, rather than crashing or remaining unresponsive.

[0064] For models marked as trainable, the validation program executes a streamlined but complete training cycle. First, the program prepares a very small training dataset within a container, typically 5-10 samples, ensuring the data format matches the model requirements. Then, the program runs the training script for 1-2 training cycles. During this process, the program monitors several key metrics: whether the training script starts and loads data correctly; whether the loss function value is calculated correctly and shows a decreasing trend or at least changes during training; whether the optimizer updates model parameters correctly; whether the log output during training is normal; and whether the checkpoint file is saved as expected. After training, the program loads the latest saved checkpoints and performs an inference validation to ensure the trained model still functions correctly. The purpose of this validation is not to train an effective model, but to confirm that all training-related code, dependencies, and environment configurations are correct.

[0065] The entire multi-level image verification unit is considered passed only after all functional verification items have passed. All logs, performance metrics, and pass / fail statuses generated during the verification process are recorded in detail and summarized into a comprehensive verification report. File hash verification, environment version verification, and configuration integrity verification ensure consistency between the image model and the original model across all critical components, avoiding functional deviations or unavailability due to synchronization errors. Interface function verification and training function verification ensure that the image model can not only respond normally to external requests but also complete complex training tasks, proving the effectiveness of the image model under various tasks. This multi-level verification approach ensures that actual model switching or deployment can only proceed after verification is passed, avoiding service interruptions caused by model version inconsistencies or unavailability.

[0066] Furthermore, the model synchronization module 12 in the automatic model synchronization and version control system for multi-model platforms is also used for: the multi-level mirror verification unit of the mirror run verification submodule further includes a model association verification subunit, which includes: an association relationship parsing channel, which is used to parse model association relationships based on the switching marker results to construct a model association graph and extract multiple associated model subsets from the model association graph; an associated mirror run channel, which is used to generate a mirror run combination for each associated model subset in the multiple associated model subsets, and perform joint run tests based on the mirror run combinations to obtain a joint impact index; the marking submodule is used to jointly switch and mark mirror run combinations that are less than a preset joint impact threshold, wherein the joint switch mark is used to establish a joint association relationship with the second type of historical version model of the multi-model local platform.

[0067] Specifically, the Model Association Validation Subunit is an advanced validation stage within the multi-level mirror validation unit, specifically designed to verify the compatibility between multiple models that have dependencies or calling relationships. When a high-risk model is updated, it may affect other related models. By constructing an association graph and running combined tests, this joint impact is assessed to ensure that model updates do not disrupt the stability of the entire model ecosystem.

[0068] The relationship resolution channel is responsible for resolving dependencies and call relationships between models. Based on the switch marker results and existing model metadata, it constructs a model relationship graph. This graph uses models as nodes and calls or data dependencies between models as edges. Then, it extracts multiple subsets of related models from this graph. Each subset represents a set of closely related models that need to be jointly tested. The relationship resolution channel reads the switch marker results of the new version of the main model to obtain its model ID. Subsequently, the channel queries the central model asset database to perform a reverse dependency retrieval. The query results may return multiple records, indicating the existence of multiple models, such as multiple different dialogue fine-tuning models, or a retrieval model in a retrieval enhancement generation process, which can be used as a base model or key component. The relationship resolution channel uses these records to dynamically construct a model relationship graph with the current new version of the main model as the root node. The construction algorithm recursively traverses: first, it adds all models that directly depend on it, then checks whether these models serve as the basis for other models. The traversal depth is usually controlled at 2-3 levels to focus on the core subgraphs that are directly affected. For example, when the main model M is updated, the fine-tuning models A and B depend on M, and the adapter C depends on B. Then the graph contains nodes M, A, B, C and the corresponding edges.

[0069] After constructing the graph, the channel will extract several subsets of related models from the graph based on the tightness of business coupling. The extraction strategy can be as follows: the strongly coupled subset includes the main model and all models that directly depend on it; the critical link subset includes the main model and all models in certain specific business links; if there are too many directly dependent models, they are grouped according to dimensions such as model owner and usage frequency to form multiple smaller subsets for parallel verification.

[0070] For each extracted subset of related models, the associated image run channel begins operation. The image run portfolio is a microservice group temporarily deployed in an isolated verification cluster, containing multiple instances of related model services. These are interconnected via a network to simulate their interaction in a production environment. The image run portfolio includes new versions of high-risk models to be switched over, as well as stable versions of other models in the subset currently running in production. All these images are deployed in the same isolated test environment, with network connections configured to simulate production-level call relationships. After deployment, joint run tests are automatically executed: a series of test requests simulating real business scenarios are sent, such as inputting a batch of test images for an image processing pipeline, allowing the requests to be processed sequentially through each model in the portfolio. Throughout the process, various joint impact metrics are monitored and collected, such as end-to-end latency, success rate, and resource utilization of each model. Joint run tests are systematic integration tests performed on the image run portfolio. Test scripts simulate end-to-end business requests, sequentially or in parallel calling the various model services in the portfolio to verify the correctness, performance, and stability of the entire workflow.

[0071] After the joint testing of all subsets is completed, the tagging submodule receives the joint impact metric report for each subset and compares each metric with a preset joint impact threshold. If all metrics for a subset are better than the threshold, such as a 100% compatibility success rate, functional deviation <3%, and performance loss <5%, then the subset is determined to be safe for collaborative updates. The tagging submodule generates a joint switching tag for each verified subset, containing the IDs and version mappings of all models within the subset. If a subset's metrics exceed the threshold, the tagging submodule generates a verification failure report, clearly indicating which associated model has a problem with which metric. The preset joint impact threshold is a safety boundary value set for the joint impact metrics, such as requiring an interface compatibility success rate of 100%, a functional consistency deviation of less than 5%, and a combined performance loss of less than 10%, used to determine whether the risk of associated updates is acceptable. The joint switching tag is a special switching tag generated by the tagging submodule. It is not only for a single model, but for a proven and safe combination of image runs, that is, a group of models. It establishes a joint association between this group of new version models and the corresponding group of old version models in the production environment, guides the system to perform atomic collaborative switching or sequential switching, and ensures the consistency of dependencies before and after the switching.

[0072] Specifically, during the joint testing process, raw data for each test case is collected, including: the call status (success or failure) of each associated model service interface, the end-to-end response time of each test case, the vector representation of the output results of each model in each test case, and system resource monitoring data. Based on the collected raw data, the success rate of all cross-model API calls is calculated. For example, if a total of 500 calls were made and 495 were successful, the success rate is 99%. For each test case, the final output of the associated model combination is compared with the historical baseline output. For example, for the text generation model, BERTScore is used to calculate the similarity between the generated text and the reference text, and then the average similarity of all test cases is calculated. Assuming the historical baseline average similarity is 0.92, while the average similarity obtained from the new combination test is 0.90, the functional consistency deviation is -2.17%. The end-to-end response time of each test case is calculated and compared with the historical baseline response time. For example, if the historical average response time is 200 milliseconds and the average response time of the new combination test is 220 milliseconds, then the combined performance loss is (220-200) / 200 = 10%. To facilitate comprehensive calculation, each sub-indicator is normalized to the [0,1] interval, where 1 represents the best (no impact) and 0 represents the worst. The normalization formula can be set according to the characteristics of the indicators. Weights are assigned to each sub-indicator based on business importance. For example, interface compatibility is the most critical, with a weight of 0.5; functional consistency is the next most critical, with a weight of 0.3; and performance loss has a weight of 0.2. Therefore, the joint impact value = 0.5 * interface compatibility normalized value + 0.3 * functional consistency normalized value + 0.2 * performance loss normalized value. The joint impact value will be compared with a preset joint impact threshold. If it is greater than or equal to the threshold, the subset of the correlation model is considered safe to update; otherwise, further review is required.

[0073] Model association verification ensures that updated models can work correctly together, avoiding errors caused by version inconsistencies or dependency issues. Joint run tests and joint impact metrics assess the safety and effectiveness of model version switching, reducing the risk of service interruption. Joint switch markers and automated verification processes automatically complete the switch during model updates, reducing manual intervention and improving efficiency.

[0074] Furthermore, the model synchronization module 12 in the automatic model synchronization and version control system for multi-model platforms is also used for: the marking submodule is used to switch the second type of model that passes the multi-level image verification unit, and to feed back the second type of model that does not pass the multi-level image verification unit to the image running verification submodule; the image running verification submodule is used to run the reconstructed model image object until it passes the multi-level image verification unit.

[0075] Specifically, the feedback and retry mechanism between the marking submodule and the image execution verification submodule constitutes a closed-loop control loop to ensure the final delivery quality of high-risk model updates. After the image execution verification submodule executes multi-level image verification units, it generates a detailed verification report containing various quantitative indicators. The marking submodule, as a decision node, does not simply receive a binary pass / fail signal, but rather parses and adjudicates the report according to preset, precise threshold rules for different levels of verification. If all indicators meet the thresholds, the marking submodule generates the final switching flag and submits it to the downstream hot update scheduling system.

[0076] If any key metric fails to meet the standard, the marking submodule is deemed unsuccessful. The task is not discarded; instead, a structured feedback instruction package is generated. This package not only contains the conclusion of failure but, more importantly, includes complete diagnostic information, clearly indicating which verification subunit failed (e.g., the image-level model functional verification subunit), the specific failure item (e.g., test cases IDF-023, F-045), relevant logs and metrics, etc. This instruction package is then fed back to the image run verification submodule.

[0077] Upon receiving feedback, the image run verification submodule does not simply retest the same image; instead, it initiates a targeted repair and re-verification process. If inconsistency verification fails, such as a file hash error, it may indicate that the original file was corrupted during transmission or build. The module will notify the image build submodule to clean up old temporary files, pull the model files from the source again, and rebuild a completely new model image object. If functional verification fails, such as a specific API call timeout or error return, it may be related to runtime environment configuration or service startup parameters. The verification submodule will combine diagnostic information, adjust resource limits or environment variables during container startup, and then rerun the verification tests using the same image, focusing on the previously failed test case set. In each retry, the system assigns a new unique identifier to the iteration and records the complete retry history. The loop continues until the image of this second type of model passes the evaluation of all multi-level image verification units. Typically, a maximum number of retries (e.g., 3 times) or a timeout window (e.g., 24 hours) is set to prevent infinite loops caused by fundamental problems that cannot be fixed. The loop terminates and outputs the final switch flag only when the verification result in a final iteration is evaluated as passed by the flagging submodule. This embodies the concept of automated access control and remediation in Continuous Integration / Continuous Deployment (CI / CD). To prevent infinite loops, a maximum number of retries (e.g., 3 times) or a total time limit is typically set. If the loop still fails after reaching the limit, it will be forcibly terminated, generating a high-priority alert requiring immediate manual intervention, and submitting the complete iteration history to engineers for analysis. Through multi-level verification and switch flag mechanisms, it is ensured that each update of the model undergoes rigorous testing, avoiding service interruptions or errors caused by improper updates.

[0078] Version control module 13 is used to compare version differences between the local platform and the external platform of multiple models, and to uniformly process the version difference files that have differences.

[0079] Specifically, the version control module is a key part of the entire system. It is responsible for comparing model versions between the local platform and the external platform. The purpose is to manage models with version differences between the two platforms in a differentiated manner, ensuring that the models can maintain consistency during synchronization and updates, and avoiding problems such as version mismatch or obsolescence on different platforms.

[0080] Model information is obtained through the API interface provided by the multi-model external platform. All directories are recursively traversed, and for each file, its path, size, last modification time, and the defined LFS file are recorded. All LFS files are parsed, the content of each LFS pointer file is obtained, and the OID (Object ID) is extracted. The actual file size and storage location are then queried using the OID. Finally, the total size and number of ordinary files in the directory, the total size and number of LFS files, and a detailed list of all files are compiled. On the multi-model local platform, the modelId is used as the primary key to query the basic record of the model in the database, obtaining basic model information such as creation time and last update time. The model directory files are traversed, and for each file, its size and hash value, permissions, creator, and all related LFS records are retrieved. The collected information is organized into the same data structure as the source platform, ensuring all necessary fields are filled for subsequent version comparisons. Basic information is compared, checking if the total number of files, the number of LFS files, and the total size. Two HashMaps are created to store file information from the original platform and the user platform. A hash algorithm is used to calculate the feature value of each file, and the content of each file is compared. For regular files, compare file sizes for consistency and check for differences in last modification times; for LFS files, compare OIDs for consistency and check file sizes. Record a list of missing files, mark files with inconsistent sizes, and count the number of files that need updating for later updates.

[0081] The system reads the configuration files from the model directory and uses a JSON parser to extract the base model's name and version number, model type (fine-tuning model, adapter, etc.), training parameters, and configuration information. For fine-tuning models, the `_name_or_path` field is particularly important, as it points to the base model. For adapter models, the `adapter_config.json` file is searched to obtain the adapter's specific configuration. A directed graph data structure is created, with the current model as a node and dependent models as related nodes. Each node contains the model's unique identifier, version number, model type (base model, fine-tuning model, adapter, etc.), and a list of dependent models. Starting from the current model, a depth-first search algorithm is used to recursively search for all dependencies. For each discovered dependent model, the database is queried to confirm its existence. If it does not exist, a new synchronization task is created, and an asynchronous task processor is used to synchronize multiple dependencies in parallel. The dependency relationships are recorded in the database, including the current model and dependent model IDs, relationship types, version information, and timestamps. Finally, files with version differences are synchronized.

[0082] Once a differing version file is identified, synchronization is not done blindly. Instead, it is processed uniformly according to preset business strategies, including one-way synchronization, conflict resolution, local cleanup, and two-way synchronization. Specifically, for new versions that are missing locally but exist externally, the model discovery module is triggered, treating them as candidate additions or changes. After evaluation and verification, these are introduced locally. For cases with the same version number but different content hashes (i.e., version conflicts), the conflict is marked. A comprehensive analysis of the credibility of the conflict source, the severity of the change, and the scope of its impact is performed, calculating a quantitative score for each dimension. The weighted total score is compared to a preset threshold: if the total score is extremely high and the source is sufficiently credible, the external version is automatically used to overwrite the local file, and a detailed audit log is generated; if the total score is extremely low or the source is suspicious, the external change is automatically ignored, and the local version is maintained; if the score falls within the middle range, a work order is automatically generated, containing conflict details, an analysis report, and recommended handling solutions, escalating to operations or algorithm engineers for manual review and final decision. The source credibility analysis is calculated using a predefined formula. Input data is obtained from the platform's public interfaces or historical records, including data source authority, publisher history, and version signature and verification. These three sub-scores are weighted and averaged (e.g., weights of 0.5, 0.3, and 0.2) to obtain the final source credibility score. Data source authority is assigned a base weight based on the type of external platform. For example, an official platform mirror has a weight of 1.0, a well-known research institution 0.9, a verified individual developer 0.7, and an anonymous source 0.3. Publisher history is calculated by querying the publisher's past synchronization success rate and problem rate, using the formula: Historical Credibility = Number of Successful Synchronizations / (Number of Successful Synchronizations + Number of Synchronizations that Caused Problems). Version signature and verification checks whether the external version has a valid digital signature, such as a GPG signature, and can be verified using the system's pre-set trusted public key. A successful verification earns full marks; otherwise, it earns zero marks. The severity of changes is first assessed using a binary differential tool to compare conflicting files and accurately calculate the proportion of changed data blocks, thus obtaining a base severity score. The types of files that have changed are identified, with changes to model weight files assigned the highest severity weight, followed by configuration file changes, and changes to documents or sample scripts assigned the lowest weight. Commit logs are parsed using a natural language processing model to identify high-risk keywords such as vulnerability fixes, major performance regressions, and incompatible changes. For each matched predefined keyword, the severity score is accumulated according to rules to obtain the change severity score. In the dependency graph, it is queried which other local models directly reference the current conflicting model, with each direct dependency receiving a base impact score. The service request volume handled by the current model over a past period is queried, and the impact coefficient is dynamically adjusted based on traffic percentiles. The model's predefined business criticality tags in the asset library are read; higher criticality tags result in a higher weighted impact range score, thus obtaining the impact range score.The credibility score of the conflict source, the severity score of the change, and the scope of impact score are input into a decision function to calculate the comprehensive score, i.e., comprehensive score = w1 * credibility score of conflict source + w2 * severity score of change + w3 * scope of impact score, where w1, w2, and w3 are weights, which are preset according to the business strategy. For example, if credibility and scope of impact are given more importance, the weights are 0.5, 0.2, and 0.3, respectively.

[0083] For versions that exist locally but have been deleted or marked as obsolete on external platforms, archive them in the multi-model local platform to free up storage space and keep the inventory clean. If the multi-model local platform is the development source and the multi-model external platform is the backup or distribution target, reverse synchronization can be configured to push the local version to the external platform.

[0084] Through automated version difference comparison and unified processing mechanisms, version differences between local and external platforms are quickly identified and handled, significantly improving the efficiency of model synchronization. The version control module can intelligently compare changes in version files and model content, avoiding conflicts and functional issues caused by version inconsistencies between different platforms. Through rollback mechanisms and logging, the system can quickly recover to a previously stable version in the event of problems, ensuring high platform availability. The rollback mechanism means that if a new version encounters problems or becomes unavailable, the version control module supports rolling back to a previous version. This involves switching user traffic away from the problematic version, and after the rollback is complete and a health check passes, switching traffic back to the recovered version, achieving a seamless recovery for users.

[0085] The multi-mechanism detection module 14 is used to perform detection and optimization processing on the models that are synchronously completed in the multi-model local platform.

[0086] Furthermore, the multi-mechanism detection module 14 in the automatic model synchronization and version control system for multi-model platforms is also used to include at least an availability detection mechanism, a hot update mechanism, and an error tolerance mechanism.

[0087] Specifically, the multi-mechanism detection module performs a series of checks and optimizations on the synchronized models to ensure their stability, availability, and performance on the local platform. The availability detection mechanism checks whether a model is in an available state by periodically or triggeredly sending test requests to the model server endpoint to check if the model can respond normally and return the expected results, thus determining the health of the model service. The hot update mechanism updates model versions without interrupting service. When a new version of the model needs to replace an older version, the hot update mechanism smoothly switches traffic from the old version to the new version, ensuring service continuity. The fault tolerance mechanism allows the model service to maintain a certain level of service capability even in the event of partial failure or anomalies. For example, when a model instance fails, the fault tolerance mechanism can temporarily remove it from the service list and forward requests to other healthy instances, or use degradation strategies such as returning cached results or using a simplified model.

[0088] The availability detection mechanism includes basic file integrity checks, LFS file (model core weight and parameter files) storage status checks, model file synchronization status checks, and computing resource availability assessments. Immediately after model synchronization, a basic file integrity check is triggered to verify the existence and hash values ​​of all necessary files in the model directory, comparing them with records from the source platform to ensure no files are missing or corrupted. Without loading the complete model, the compatibility of the model configuration file with the local inference framework is checked, and the required dependencies are verified to be installed and version-matched. Using a very small but representative set of test data, the model is loaded and forward inference is executed once to verify whether the model can be successfully instantiated, whether the weights can be loaded correctly, and whether the basic computation path is unobstructed. Resource consumption and exceptions during this process are strictly monitored. For models encapsulated as API services, their health check endpoints are periodically called to monitor the service's HTTP status codes and response latency, ensuring they are in a serviceable state. In other words, basic file integrity verification is triggered immediately after model synchronization, calculating the cryptographic hash value of the local model file and comparing it with the hash value recorded by the external platform to ensure no files are missing or corrupted. Next, by parsing specific fields in the model configuration file, a structured comparison is performed with the package manifest in the local runtime environment to verify framework compatibility and dependency version matching. In the lightweight functional verification phase, the model's core computation graph is loaded in an isolated environment, and a complete forward inference is executed using a set of pre-defined standard test data. The process is monitored for exceptions and whether resource consumption is within expectations. For deployed service instances, structured query requests are periodically sent to their management endpoints, and the returned status codes, response latency, and key metadata are verified to confirm their service readiness.

[0089] The hot update mechanism includes pre-processing status checks, resource pre-allocation, dual-version operation, and version switching. It is the core mechanism for achieving zero-downtime model version switching. Once the new version model, after image synchronization and verification, is ready, the hot update mechanism ensures a seamless upgrade for users. Upon receiving a switch marker, the hot update mechanism allocates computing resources in the resource pool that match the current production environment specifications, deploys the new version model instance, and performs a rapid health check. After the new version model instance passes the health check, it dynamically modifies the traffic distribution rules using a progressive weight adjustment strategy by calling the load balancing component's configuration management interface. Typically, 1% of traffic is initially switched to the new version to observe the error rate and latency; if stable, the proportion is gradually increased to 100% within 10 minutes. After confirming stable operation of the new version for a period of time, such as 30 minutes, and that all monitoring metrics are normal, the mechanism automatically reduces the number of current production instances to zero and releases their resources. The old version model files and images are retained in the system for a period of time for emergency rollback.

[0090] The error tolerance mechanism supports complete state tracking for model synchronization, using explicit state enumerations (waiting, in progress, successful, failed, already existing), and records the synchronization start and end times. It supports multiple protection mechanisms for model synchronization: distributed locks to prevent concurrency issues; transaction management to ensure data consistency; a deduplication mechanism to avoid redundant processing; support for asynchronous processing and automatic retries on failures; and a robust logging system using MDC to record tracking IDs and detailed error information and critical node states. The error tolerance mechanism permeates all aspects of model management, aiming to predict, absorb, and recover from runtime failures, ensuring overall system availability. A clear state machine is maintained for each synchronization and update operation, and critical operations are guaranteed atomicity using database transactions to avoid intermediate states. For failed operations due to network jitter or temporary unavailability of dependent services, such as file download failures or API call timeouts, the error tolerance mechanism automatically retrys. The retry strategy uses exponential backoff, such as retries after 1 second, 2 seconds, 4 seconds, up to a maximum of 3 times, to prevent cascading failures. When a model service continues to fail or responds too slowly, the error tolerance mechanism can trigger a circuit breaker, temporarily diverting requests to a backup model or returning a friendly degradation result, such as returning a cached result or indicating that the service is being optimized, preventing the failure from spreading and dragging down the entire system. The mechanism is deeply integrated with the monitoring system, defining a series of key metrics, such as synchronization success rate, service error rate, and P99 latency. When a metric exceeds a threshold, an alarm is automatically triggered, and self-healing scripts can be preset, such as automatically restarting the faulty instance.

[0091] Through multi-mechanism detection, issues after model synchronization are effectively detected and resolved, preventing model instability or unavailability. The availability detection mechanism provides a real-time health view, ensuring faults are detected and addressed before impacting users. The hot update mechanism is the core of the model's rapid iteration capability, allowing model optimization and bug fixing to occur at any time without scheduling maintenance windows that impact business operations, reducing downtime for model iteration to zero and significantly improving business agility and user experience. The fault tolerance mechanism, through a series of preset resilience modes, enables the system to gracefully cope with internal faults and external shocks, preventing the spread of localized faults and ensuring that core business operations continue to run even when some components fail, significantly improving the system's resilience and business continuity.

[0092] In summary, the automatic model synchronization and version control system for multi-model platforms provided in this application has the following technical effects: It monitors and classifies models on multiple model platforms in real time through a model discovery module; it introduces a reinforcement learning mechanism in the impact assessment submodule to dynamically optimize the assessment strategy for the impact of model synchronization; it combines a synchronization submodule and a mirror synchronization submodule to implement differentiated synchronization strategies for models with different impact levels; it ensures model consistency and accuracy through version difference comparison and processing; it introduces a multi-mechanism detection module to optimize synchronized models; and it utilizes reinforcement learning for continuous optimization detection and hot update strategies to ensure accurate synchronization of model files from multiple platforms to its own platform. This improves the efficiency and accuracy of model synchronization across multiple model platforms and further enhances the overall stability of the multi-model platform.

[0093] Example 2: Based on the same inventive concept as the automatic model synchronization and version control system for multi-model platforms in Example 1, this application also provides an automatic model synchronization and version control method for multi-model platforms. Please refer to the appendix. Figure 2 The automatic model synchronization and version control method for multi-model platforms includes: detecting a first type of model and a second type of model on the external multi-model platform; evaluating the impact of the second type of model; performing model synchronization for the first type of model and for models in the second type of model with an impact less than a preset synchronization threshold; performing model synchronization for models in the second type of model with an impact greater than or equal to the preset synchronization threshold; comparing version differences between the local multi-model platform and the external multi-model platform; uniformly processing differing version files; and detecting and optimizing the synchronized models on the local multi-model platform.

[0094] Furthermore, the access interface unit includes multiple access interfaces, and collects the model metadata set of the multi-model external platform based on the multiple access interfaces, wherein the model metadata is a fingerprint digest representing the model file; by comparing the received model metadata set with the model metadata set of the multi-model local platform, a first type of model and a second type of model are obtained, wherein the first type of model is a newly added model obtained by comparison, and the second type of model is a changed model obtained by comparison.

[0095] Furthermore, the automatic model synchronization and version control method for multi-model platforms includes: extracting model change feature vectors from the metadata set of the second type of model corresponding to the second type of model, including the proportion of model parameter changes, the degree of model structure change, the change of model samples, and the magnitude of model performance changes; using a pre-constructed synchronization impact function to perform weighted calculation on the model change feature vectors to obtain the impact evaluation result of the second type of model.

[0096] Furthermore, the automatic model synchronization and version control method for multi-model platforms includes: performing model synchronization of the first type of model, including creating an initial version identifier on the multi-model local platform, and synchronizing the first type of model to the multi-model local platform by reading the first type of model metadata set of the first type of model.

[0097] Furthermore, the construction of the model image object includes a set of model files, model runtime environment information, model configuration parameters and interfaces, and model dependencies; the model image object is synchronized to a local image storage area, which is logically isolated from the model runtime area of ​​the multi-model local platform; the model image object is run and a multi-level image verification unit is executed; the second type of model is marked for switching according to the multi-level image verification unit, and the switching mark result is sent to the multi-model local platform; wherein, the switching mark is used to establish the association between the marked second type of model and the second type of historical version model of the multi-model local platform.

[0098] Furthermore, the multi-level mirror verification unit includes a mirror-level model consistency verification subunit and a mirror-level model function verification subunit; the mirror-level model consistency verification subunit includes model file hash consistency verification, runtime environment version matching verification, and configuration parameter integrity verification; the mirror-level model function verification subunit includes interface function callability verification and training function integrity verification.

[0099] Furthermore, the automatic model synchronization and version control method for multi-model platforms includes: constructing a model association graph by parsing the model association relationship based on the switching marker result, and extracting multiple associated model subsets from the model association graph; generating a mirror run combination for each associated model subset in the multiple associated model subsets, conducting joint run tests based on the mirror run combinations, and obtaining a joint impact index; and marking the mirror run combinations that are less than a preset joint impact threshold with a joint switching marker, wherein the joint switching marker is used to establish a joint association relationship with the second type of historical version model of the multi-model local platform.

[0100] Furthermore, the automatic model synchronization and version control method for multi-model platforms includes: marking the second type of models that pass the multi-level image verification unit as switched; feeding back the second type of models that do not pass the multi-level image verification unit to the image running verification submodule; running the reconstructed model image object until it passes the multi-level image verification unit.

[0101] Furthermore, the multi-mechanism detection module includes at least an availability detection mechanism, a hot update mechanism, and an error tolerance mechanism.

[0102] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The automatic model synchronization and version control system and specific examples for multi-model platforms in the foregoing embodiment one are also applicable to the automatic model synchronization and version control method for multi-model platforms in this embodiment. Through the foregoing detailed description of the automatic model synchronization and version control system for multi-model platforms, those skilled in the art can clearly understand the automatic model synchronization and version control method for multi-model platforms in this embodiment. Therefore, for the sake of brevity, it will not be described in detail here.

[0103] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0104] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of this application and its equivalents, this application also intends to include such modifications and variations.

Claims

1. An automatic model synchronization and version control system for multi-model platforms, characterized in that, include: A model discovery module, which is used to detect first-class and second-class models on multiple external model platforms; The model synchronization module includes an impact assessment submodule, a synchronization submodule, and a mirror synchronization submodule. The impact assessment submodule is used to assess the impact of the second type of model. The synchronization submodule is used to perform model synchronization of the first type of model and model synchronization of the second type of model with an impact less than a preset synchronization value. The mirror synchronization submodule is used to perform model synchronization of the second type of model with an impact greater than or equal to the preset synchronization value. The version control module is used to compare the version differences between the local platform and the external platform of the multi-model, and to uniformly process the version difference files that have differences. A multi-mechanism detection module is used to perform detection and optimization processing on the models that are synchronously completed in the multi-model local platform.

2. The automatic model synchronization and version control system for multi-model platforms as described in claim 1, characterized in that, The model discovery module includes: An access interface unit, comprising multiple access interfaces, collects a set of model metadata from the external platform of the multi-model based on the multiple access interfaces, wherein the model metadata is a fingerprint digest representing the model file; The model partitioning unit compares the received model metadata set with the model metadata set of the multi-model local platform to obtain a first type of model and a second type of model. The first type of model is a newly added model obtained by comparison, and the second type of model is a changed model obtained by comparison.

3. The automatic model synchronization and version control system for multi-model platforms as described in claim 1, characterized in that, The impact assessment submodule includes: The feature extraction unit is used to extract model change feature vectors from the metadata set of the second type of model corresponding to the second type of model, including the proportion of model parameter changes, the degree of model structure change, the model sample change situation, and the magnitude of model performance change. The impact calculation unit includes a pre-constructed synchronous impact function, which is used to perform weighted calculation on the model change feature vector to obtain the impact evaluation result of the second type of model.

4. The automatic model synchronization and version control system for multi-model platforms as described in claim 1, characterized in that, The synchronization submodule is used to perform model synchronization of the first type of model, including creating an initial version identifier on the multi-model local platform and synchronizing the first type of model to the multi-model local platform by reading the first type of model metadata set of the first type of model.

5. The automatic model synchronization and version control system for multi-model platforms as described in claim 1, characterized in that, The mirror synchronization submodule is used to perform model synchronization in the second type of model where the synchronization influence is greater than or equal to the preset synchronization influence, including: The image building submodule is used to build a model image object, including a collection of model files, model runtime environment information, model configuration parameters and interfaces, and model dependencies. An isolation synchronization submodule is used to synchronize the model image object to a local image storage area, wherein the local image storage area is logically isolated from the model running area of ​​the multi-model local platform. The image execution verification submodule runs the model image object and executes multi-level image verification units. The marking submodule is used to switch the second type of model according to the multi-level mirror verification unit and send the switching marking result to the multi-model local platform. The switching marker is used to establish the association between the second type of model marked and the second type of historical version model of the multi-model local platform.

6. The automatic model synchronization and version control system for multi-model platforms as described in claim 5, characterized in that, The multi-level image verification unit of the image operation verification submodule includes an image-level model consistency verification subunit and an image-level model function verification subunit. The mirror-level model consistency verification subunit includes model file hash consistency verification, runtime environment version matching verification, and configuration parameter integrity verification. The mirror-level model function verification subunit includes interface function callability verification and training function integrity verification.

7. The automatic model synchronization and version control system for multi-model platforms as described in claim 5, characterized in that, The multi-level mirror verification unit of the mirror operation verification submodule further includes a model association verification subunit, which includes: The association relationship parsing channel is used to parse the model association relationship based on the switching marker result, construct a model association graph, and extract multiple associated model subsets from the model association graph; A related mirror running channel is used to generate a mirror running combination for each of the multiple related model subsets, and to conduct joint running tests based on the mirror running combination to obtain joint impact indicators. The marking submodule is used to mark mirror run combinations that are less than a preset joint influence threshold for joint switching. The joint switching marker is used to establish a joint association relationship with the second type of historical version model of the multi-model local platform.

8. The automatic model synchronization and version control system for multi-model platforms as described in claim 5, characterized in that, The marking submodule is used to switch the marking of the second type of model that passes the multi-level mirror verification unit, and to feed back the second type of model that does not pass the multi-level mirror verification unit to the mirror run verification submodule; The image run verification submodule is used to run the reconstructed model image object until it passes the multi-level image verification unit.

9. The automatic model synchronization and version control system for multi-model platforms as described in claim 1, characterized in that, The multi-mechanism detection module includes at least an availability detection mechanism, a hot update mechanism, and an error tolerance mechanism.

10. An automatic model synchronization and version control method for multi-model platforms, characterized in that, The automatic model synchronization and version control method for multi-model platforms, as described in any one of claims 1 to 9, comprises: Detecting Class I and Class II models on a multi-model external platform; The impact of the second type of model is evaluated, and the model synchronization of the first type of model and the model synchronization of the second type of model with an impact less than the preset synchronization value are performed. The model synchronization of the second type of model with an impact greater than or equal to the preset synchronization value is also performed. Compare the version differences between the local platform and the external platform for multiple models, and process the version difference files with differences in a unified manner. The models that are synchronously completed in the multi-model local platform are subjected to detection and optimization processing.

Images