A model management method, apparatus, device, storage medium, and program product

Abstract

This invention discloses a model management method, apparatus, device, storage medium, and program product. Based on the requirements of model lifecycle management, a modular design method is used to construct several independent management modules and their functional configuration information. According to the needs of the business scenario and the model feature data of existing model versions, a model version adapted to the business scenario is obtained, and the current model is determined and deployed. When preset model switching conditions are met, a model switching window is determined based on the task queue and resource status. Based on the weight parameters of the current model and the target model, the drift risk during the model switching process is assessed, and a weight correction scheme is formulated. In the model switching window, the current model is switched to the target model, and model correction is performed according to the weight correction scheme. Using this invention, the problems of coupling between various links in the model management process, rigid adaptation to business scenarios, and high risk of model version switching can be solved, improving the flexibility and intelligence of model management.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a model management method, apparatus, device, storage medium, and program product. Background Technology

[0002] Large-scale pre-trained models have become a core tool for solving complex problems, and have performed well in fields such as natural language processing, image recognition, and recommendation systems.

[0003] While large-scale models have demonstrated significant advantages in fields such as natural language processing, image recognition, and recommendation systems, they currently exhibit certain limitations in the development and maintenance of large-scale pre-trained models. Traditional model management methods suffer from high coupling between different stages, leading to mutual interference during multi-task, multi-model parallel development. Optimizing a single stage requires modifying the entire system, resulting in inefficient model management. Furthermore, existing models lack dynamic adaptation mechanisms, with all business scenarios using the same model version, causing inefficiency and resource waste. In addition, model version switching carries high risks, potentially leading to task queue loss, inconsistent inference results, or even business interruptions. This is particularly problematic in high real-time scenarios, where performance fluctuations can significantly impact business stability. Summary of the Invention

[0004] The purpose of this invention is to provide a model management method, apparatus, device, storage medium, and program product that can solve the problems of coupling between various links in the model management process, rigid adaptation to business scenarios, and high risk of model version switching, thereby improving the flexibility and intelligence of model management.

[0005] To achieve the above objectives, embodiments of the present invention provide a model management method, comprising: Based on the model's full lifecycle management requirements, a modular design approach is adopted to construct several independent management modules and their functional configuration information; Based on the needs of the business scenario and the model feature data of the existing model version, obtain the model version that is compatible with the business scenario, and determine and deploy the current model for the business scenario based on the model version. When the preset model switching conditions are met, the model switching window is determined based on the task queue and resource status of the current model; Based on the weight parameters of the current model and the target model to be switched, assess the drift risk of the model inference results during the model switching process, and formulate a weight correction scheme for each network layer of the model. In the model switching window, the current model is switched to the target model, and the current model after switching is corrected according to the weight correction scheme.

[0006] As an improvement to the above solution, the management module includes a development module, a training module, a testing module, a deployment module, and an operation and maintenance module, which are respectively used for the development, training, testing, deployment, and operation and maintenance of the management model; Based on the model's full lifecycle management requirements, a modular design approach is used to construct several independent management modules and their functional configuration information, including: Based on the model's full lifecycle management requirements, a modular design approach is adopted to construct each independent management module. Based on the functional requirements of each management module, the functional boundaries of each management module are determined, data transmission standards and functional protocols are unified, and an interface specification document for each management module is generated. Each management module is encapsulated using a pre-defined containerization tool, a containerized configuration file is built, and the configuration file is loaded by running the containerization tool to generate a module container image; The management module is deployed in a distributed manner by loading the module container image and running the instance using a preset deployment tool.

[0007] As an improvement to the above solution, the step of obtaining a model version suitable for the business scenario based on the needs of the business scenario and the model feature data of existing model versions, and determining and deploying the current model for the business scenario based on the model version, includes: Obtain the requirement feature data of the business scenario and the model feature data of the existing model version; The demand feature data and the model feature data are normalized using a data normalization method to obtain normalized demand feature vectors and model feature vectors. Based on the normalized demand feature vector and model feature vector, the similarity is calculated using the cosine similarity formula. Based on the similarity, a model version that is compatible with the current business scenario is determined and denoted as the first model version; The version management system is used to load the runtime configuration file of the first model corresponding to the first model version, and the scale configuration of the model instance of the first model is obtained. Based on the runtime configuration file and the scale configuration, it is determined whether the model instance needs to be scaled. If a scaling adjustment is required, a model scaling adjustment suggestion is generated; wherein, the scaling adjustment suggestion includes whether to expand or shrink the current size; Based on the model size adjustment suggestions, the model instance is adjusted using model compression and expansion algorithms to generate the current model for the business scenario, and the current model is then deployed.

[0008] As an improvement to the above scheme, the step of determining the model switching window based on the current model's task queue and resource status when the preset model switching conditions are met includes: When the preset model switching conditions are met, the task queue and resource status of the current model are obtained; wherein, the task queue includes high-priority tasks and low-priority tasks; The estimated completion time of the high-priority tasks in the task list is determined based on the resource status. Based on the estimated completion time, the completion time of the high-priority task is determined as the model switching window.

[0009] As an improvement to the above scheme, the step of assessing the drift risk of model inference results during model switching based on the weight parameters of the current model and the target model to be switched, in order to formulate a weight correction scheme for each network layer of the model, includes: Obtain the weight parameters of each network layer of the current model and the target model to be switched; Compare the similarity of the weight parameters of each network layer of the current model and the target model; Based on the similarity of the weight parameters, assess the risk of drift in the model inference results during model switching; Based on the drift risk, a weight adjustment scheme is formulated for each of the network layers; wherein the weight adjustment scheme includes an adjustment strategy for the weight parameters of each of the network layers.

[0010] As an improvement to the above solution, the step of switching the current model to the target model in the model switching window includes: In the model switching window, the model version of the target model is loaded through an asynchronous hot-swapping mechanism; The resource allocation strategy is invoked to load the parameters required by the target model into memory, and the target model is initialized using the model instantiation method.

[0011] As an improvement to the above solution, after deploying the current model of the aforementioned business scenario, the method further includes: Real-time monitoring of key indicator data during the operation of the current model; When the key indicator data exceeds the corresponding preset standard threshold, an abnormal situation is determined and an alarm is triggered; When an abnormal situation occurs, it is determined whether there is a backup model; wherein, the backup model is the historical model corresponding to the historical model version with the highest stability that has a similarity greater than a preset similarity threshold with the current model version. When a backup model exists, the system will switch to the backup model for operation. When no backup model is available, a retraining mechanism is triggered, employing gradient descent and hyperparameter search algorithms to adjust the parameters of the current model and generate a new, repaired model.

[0012] As an improvement to the above solution, the method further includes: By integrating the runtime status data of all historical model versions, the cosine similarity algorithm is used to calculate the similarity between different model versions, and a version association map is generated to show the optimization paths between model versions. Based on the version correlation graph, predict the future performance trend data of the model version, and generate model optimization suggestions based on the future performance data and key influencing factors.

[0013] This invention also provides a model management device, comprising: The modular design module is used to construct several independent management modules and their functional configuration information based on the model's full lifecycle management requirements using a modular design approach. The model configuration module is used to obtain a model version that is compatible with the business scenario based on the requirements of the business scenario and the model feature data of the existing model version, and to determine and deploy the current model of the business scenario based on the model version. The model switching module is used to determine the model switching window based on the task queue and resource status of the current model when preset model switching conditions are met; and, Based on the weight parameters of the current model and the target model to be switched, assess the drift risk of model inference results during model switching to formulate a weight adjustment scheme for each network layer of the model; and, In the model switching window, the current model is switched to the target model, and the current model after switching is corrected according to the weight correction scheme.

[0014] This invention also provides a model management device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement the model management method as described in any of the preceding embodiments.

[0015] This invention also provides a computer-readable storage medium, which includes a stored computer program, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to execute the model management method as described in any of the above embodiments.

[0016] This invention also provides a computer program product, which includes a computer program or computer instructions. When the computer program or computer instructions are executed by a processor, they implement the model management method as described in any of the above embodiments.

[0017] Compared with existing technologies, the model management method, apparatus, device, storage medium, and program product disclosed in this invention, through a modular design approach, divides the entire model lifecycle management process into multiple independent management modules, improving system flexibility and scalability while reducing the complexity of managing large models throughout their lifecycle. Based on scenario requirement data and model performance monitoring data, it accurately matches the most suitable model version for the business scenario, solving the problem of model-business mismatch in traditional methods. Utilizing dynamic hot-switching technology to generate asynchronous model switching plans, combined with a weight correction mechanism, it effectively optimizes model version switching efficiency, reduces the risk of inference result drift, and ensures business continuity. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a model management method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a model management device provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a model management device provided in an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] In the description of this application, it should be understood that the terms "center", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0021] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0022] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0023] See Figure 1 This is a flowchart illustrating a model management method provided in an embodiment of the present invention. The embodiment of the present invention provides a model management method, including steps S11 to S15: S11. Based on the model's full lifecycle management requirements, a modular design approach is adopted to construct several independent management modules and their functional configuration information; S12. Based on the needs of the business scenario and the model feature data of the existing model version, obtain a model version that is compatible with the business scenario, and determine and deploy the current model of the business scenario based on the model version. S13. When the preset model switching conditions are met, determine the model switching window based on the task queue and resource status of the current model. S14. Based on the weight parameters of the current model and the target model to be switched, assess the drift risk of the model inference results during the model switching process, and formulate a weight correction scheme for each network layer of the model. S15. In the model switching window, switch the current model to the target model, and correct the current model after switching according to the weight correction scheme.

[0024] Preferably, the management module includes a development module, a training module, a testing module, a deployment module, and an operation and maintenance module, which are used for the development, training, testing, deployment, and operation and maintenance of the management model, respectively.

[0025] In this embodiment of the invention, to address the problems of severe coupling between various stages, rigid model adaptation, and high risk of model switching in existing model management processes, this embodiment divides the entire process into five independent stages: development, training, testing, deployment, and operation and maintenance, based on the requirements of full lifecycle model management. Corresponding development, training, testing, deployment, and operation and maintenance modules are constructed for each stage. Each management model is responsible for its own specific function, with clearly defined input / output data structures and functional boundaries, and corresponding functional configuration information is configured for each management model. The management modules do not interfere with each other; optimizing any stage does not require pausing other stages. For example, optimizing the training stage does not require pausing deployment and operation and maintenance services, improving the efficiency of multi-task parallel development and significantly enhancing the system's flexible scalability.

[0026] Furthermore, when specific business scenarios require specific model versions, based on the needs of the business scenario and the model feature data of existing model versions, similarity calculation and other methods are used to obtain a model version that is compatible with the business scenario. The current model for the business scenario is determined based on the model version, and the current model is deployed. This allows for rapid adjustment of the model version and configuration according to the input data scale, inference speed, and computing resource requirements of different business scenarios. This helps avoid a one-size-fits-all approach of using the same model version regardless of the business scenario, and helps to balance memory usage and running speed, thereby optimizing resource utilization.

[0027] Furthermore, when preset model switching conditions are met, the task queue of the current model is monitored, including currently running or pending high-priority and low-priority tasks, as well as the current resource status, including CPU utilization and runtime utilization. Based on this information, a low-load period is determined as the model switching window. Additionally, based on the weight parameters of the current model and the target model to be switched to, the similarity between the two is compared to assess the drift risk of model inference results during the model switching process. This allows for the development of weight correction schemes for each network layer of the model. For example, if there is a risk of inconsistent inference results, such as a potential decrease in prediction accuracy, then layers with significant differences need to be fine-tuned to ensure stable results after the switch. During the model switching window, the new model is asynchronously loaded, switching the current model to the target model. Real-world task performance (response time, accuracy) is simulated for testing. Once the performance targets are met, the task queue is migrated, ensuring uninterrupted business operations throughout the process. The current model is then corrected according to the weight correction scheme to ensure zero loss rate during version switching and improve the consistency of inference results, thus guaranteeing business stability in high-real-time scenarios.

[0028] By employing the technical means of this invention and using a modular design approach, the entire model lifecycle management process is divided into multiple independent management modules, improving the system's flexibility and scalability while reducing the complexity of managing large models throughout their lifecycle. Based on scenario requirement data and model performance monitoring data, the most suitable model version for the business scenario is accurately matched, solving the problem of model-business mismatch in traditional methods. Dynamic hot-switching technology is used to generate asynchronous model switching plans, combined with a weight correction mechanism, effectively optimizing model version switching efficiency, reducing the risk of inference result drift, and ensuring business continuity.

[0029] As a preferred embodiment, the present invention further implements the above embodiments, wherein step S11, namely, constructing several independent management modules and their functional configuration information using a modular design method according to the model's full lifecycle management requirements, includes steps S111 to S114: S111. Based on the model's full lifecycle management requirements, a modular design approach is adopted to construct each independent management module; S112. Based on the functional requirements of each management module, determine the functional boundaries of each management module, unify the data transmission standards and functional protocols, and generate an interface specification document for each management module. S113. Each management module is encapsulated using a pre-defined containerization tool, a containerization configuration file is built, and the configuration file is loaded by running the containerization tool to generate a module container image. S114. Load the module container image and run the instance using a preset deployment tool to perform distributed deployment of the management module.

[0030] In this embodiment of the invention, a modular design approach is adopted to construct five independent management modules, including development, training, testing, deployment, and operation and maintenance. The input and output data structures are determined and the functional boundaries are defined, and module interface specification documents are generated.

[0031] Specifically, based on the requirements of model lifecycle management, a modular design approach is adopted to construct five independent management modules, including development, training, testing, deployment, and operation and maintenance. By analyzing the functional requirements of each module, the input and output data structures and functional requirements of the module are obtained. A functional decomposition algorithm is used to determine the functional boundaries of each module, generating a list of functional module definitions. Data transmission standards and functional protocols are defined through interface abstraction technology, resulting in module interface documentation that supports flexible expansion. Based on the module interface documentation, each core module is encapsulated using the containerization tool Docker, obtaining the module's execution environment configuration, including dependency packages, computing resource requirements, and operational parameters, and constructing a containerized configuration file. The configuration file is loaded by running the containerization tool, generating a module container image. The container image is then loaded and run using Kubernetes deployment tools, resulting in a module runtime instance supporting distributed deployment.

[0032] For example, based on the needs of model lifecycle management, such as a company needing to develop a text classification model for customer review sentiment analysis, a modular design approach is adopted, dividing the model development, training, testing, deployment, and operation into five independent modules. The development module defines the model structure and selects a pre-trained model, such as BERT. Its input is the user-provided task requirements document and data preprocessing specifications, and its output is the model's initial configuration file, such as in JSON format, containing the number of model layers, the number of neurons per layer, etc. The training module performs distributed training based on the model configuration file output by the development module. Its input is a labeled sentiment classification dataset, such as containing 100,000 text samples, and its output is an optimized model weight file. The testing module evaluates the performance of the trained model. Its input is a test dataset and the model weight file, and its output is a model evaluation metric report, such as an accuracy of 95% and an F1 score of 0.92. The deployment module containerizes the trained model, relying on TensorFlow 2.0 and the NLP toolkit spaCB2. Computational resource requirements include an NVIDIA T4 GPU with 16GB of VRAM, and a parallel thread count of 4. The operations module monitors model performance during runtime, taking runtime logs and real-time request data as input and key performance indicators as output, such as an average response time of 50ms and an error rate of 0.5%. Based on the above functional requirements, a functional decomposition algorithm is used to determine module boundaries, generating a list of functional module definitions. Inputs, outputs, and functional requirements are explicitly recorded in the interface specification document. According to the interface specification document, each module is packaged using Docker. For example, the training module is packaged as an image. The execution environment configuration file defines the TensorFlow 2.0 installation method, data loading path, and training parameter configuration, with a learning rate of 0.001 and a batch size of 32. After generating a module container image using the containerization tool, the image is loaded into a distributed environment using the Kubernetes deployment tool. Two GPU instances are allocated to the training module to support parallel training, generating a module running instance that supports distributed deployment, ensuring that the module can be flexibly scaled and run efficiently.

[0033] By employing the technical means of this invention, the entire model management process is divided into five independent stages: development, training, testing, deployment, and operation and maintenance. Corresponding management modules are constructed for management, with each module responsible for its own specific function. The input and output data structures and functional boundaries are clearly defined, and the interfaces are standardized and containerized for deployment. The modules do not interfere with each other, and the optimization of any module in any stage does not require pausing modules in other stages, effectively improving the efficiency of multi-task parallel development and greatly enhancing the system's flexible scalability.

[0034] As a preferred embodiment, this invention further implements the above embodiments, wherein step S12, namely, obtaining a model version adapted to the business scenario based on the needs of the business scenario and the model feature data of the existing model version, and determining and deploying the current model of the business scenario based on the model version, includes steps S121 to S128: S121. Obtain the requirement feature data of the business scenario and the model feature data of the existing model version; S122. The demand feature data and the model feature data are normalized using a data normalization method to obtain normalized demand feature vectors and model feature vectors. S123. Based on the normalized demand feature vector and model feature vector, the similarity is calculated using the cosine similarity calculation formula. S124. Determine a model version that is compatible with the current business scenario based on the similarity, and denot it as the first model version; S125. Using a version management system, load the runtime configuration file of the first model corresponding to the first model version, and obtain the scale configuration of the model instance of the first model. S126. Determine whether the model instance needs to be scaled based on the running configuration file and the scale configuration; S127. If a scale adjustment is required, a model scale adjustment suggestion is generated; wherein, the scale adjustment suggestion includes whether to expand or shrink the current scale; S128. Based on the model size adjustment suggestions, the model instance is adjusted using model compression and expansion algorithms to generate the current model for the business scenario, and the current model is deployed.

[0035] In this embodiment of the invention, the similarity between the requirements and the model version is calculated based on the scenario requirement data and the model performance monitoring data, and the model scale configuration scheme of the most suitable version is formulated.

[0036] Specifically, data acquisition tools are used to obtain the requirement feature data of the scenario, including the input data scale, inference speed requirements, and memory usage limits. Model performance monitoring tools are used to obtain the model feature data of existing model versions, including accuracy, speed, memory usage, and computing resource requirements. Data normalization methods are used to normalize the scenario requirement data and model performance data, resulting in normalized requirement features and model feature vectors. Based on the normalized requirement features and model feature vectors, the cosine similarity calculation formula is used to calculate the similarity between the real-time scenario requirements and the feature vectors of all model versions in batches. By sorting the similarity scores, the model version most suitable for the current scenario requirements is determined, and the optimal matching result is recorded.

[0037] Based on the model version best suited to the current scenario requirements, the corresponding model's runtime configuration file is loaded using a version management system to obtain the model instance's scale configuration, including the number of parameters, computation node distribution, and memory usage. By comparing the runtime configuration of the best-suited model version with the current model instance's scale configuration, it is determined whether the current model instance needs to be scaled up. If so, a model scale adjustment suggestion is generated, including whether to expand or shrink the current scale.

[0038] Based on model scaling recommendations, the current model instance is adjusted using model compression and expansion algorithms. Optimization tools are invoked to load the current model parameters and structure, and pruning or quantization operations are performed to compress the scale, or a certain number of computing nodes are allocated for parallel expansion according to task requirements. The adjusted model scaling configuration data is obtained, and the parameter and node distribution information of the optimized model is recorded to formulate a model scaling configuration plan.

[0039] For example, if a sentiment analysis task requires classification based on real-time customer feedback data, the platform uses data acquisition tools to obtain the required feature data for the current scenario. The input data scale is 1000 texts per second, the inference speed requirement is no more than 50 milliseconds per text, and the memory usage limit is no more than 8GB per instance. Information about the existing model version is obtained through model performance monitoring tools, revealing that a certain version of the model has the following features: classification accuracy of 92%, inference speed of 60 milliseconds / text, memory usage of 10GB, and computing resource requirement of 1 GPU per instance. The scenario requirement data and model performance data mentioned above were processed using a normalization method. The range of inference speed requirements and actual speeds were mapped to a standardized interval of 0 to 1. Memory usage and resource requirements were normalized according to their relative proportions. The resulting normalized scenario requirement feature vectors are 0.8, 0.7, 0.6, 0.8, 0.7, 0.6, 0.7, 0.6, representing inference speed, memory usage limits, and data scale, respectively. The existing model feature vectors are 0.6, 0.5, 0.8, 0.6, 0.5, 0.8, 0.6, 0.5, 0.8. Based on the normalized feature vectors, the cosine similarity formula was used to calculate the similarity between the real-time scenario requirements and the feature vectors of all model versions, which was 0.92. By calculating and sorting the similarity scores of each model version, the model version most suitable for the current scenario requirements was determined. The results show that the most suitable model version for the current requirements is version A1. Based on the runtime configuration file of the optimal model version A1, its scale configuration is loaded, for example, 50 million parameters, single GPU computing node distribution, and 8GB memory usage. By comparing the runtime configuration of the optimal model version A1 with the scale configuration of the current model instance, it is determined that the current instance needs to be scaled. The current model instance's scale configuration has 70 million parameters, dual GPU distribution, and 10GB memory usage. Since the current model scale exceeds the requirements, model scale adjustment suggestions are generated, including compressing the number of parameters to 50 million, reducing one GPU instance, and adjusting memory usage to 8GB. Model compression and expansion algorithms are used, redundant parameters are reduced by 20% through weight pruning, and memory usage priority is reallocated through memory optimization algorithms. Finally, the adjusted model scale configuration data is obtained, including the new parameter distribution and node distribution. The adjusted model instance configuration is recorded as 50 million parameters, single GPU distribution, and 8GB memory usage, and a model scale configuration plan is formulated for update deployment.

[0040] By employing the technical means of this invention, intelligent matching and scale adjustment of models under various business scenarios can be achieved through scenario requirements and performance data of existing model versions. This can effectively avoid the one-size-fits-all approach of using the same model version for different business scenarios, and is conducive to balancing memory usage and running speed, thereby optimizing resource utilization.

[0041] As a preferred embodiment, the present invention is further implemented based on any of the above embodiments. Step S13, namely, determining the model switching window based on the current model's task queue and resource status when the preset model switching conditions are met, includes steps S131 to S133: S131. When the preset model switching conditions are met, obtain the task queue and resource status of the current model; wherein, the task queue includes high-priority tasks and low-priority tasks; S132. Determine the estimated completion time of the high-priority tasks in the task list based on the resource status; S133. Based on the estimated completion time, determine the completion time of the high-priority task as the model switching window.

[0042] In a preferred embodiment, step S14, namely, assessing the drift risk of model inference results during model switching based on the weight parameters of the current model and the target model to be switched, in order to formulate a weight correction scheme for each network layer of the model, includes steps S141 to S144: S141. Obtain the weight parameters of each network layer of the current model and the target model to be switched; S142. Compare the similarity of the weight parameters of each network layer of the current model and the target model; S143. Based on the similarity of the weight parameters, assess the drift risk of the model inference results during the model switching process; S144. Based on the drift risk, formulate a weight correction scheme for each of the network layers; wherein the weight correction scheme includes an adjustment strategy for the weight parameters of each of the network layers.

[0043] In a preferred embodiment, step S15, namely switching the current model to the target model in the model switching window, includes steps S151 and S152: S151. In the model switching window, the model version of the target model is loaded through an asynchronous hot-switching mechanism; S152. Invoke the resource allocation strategy to load the parameters required by the target model into memory, and initialize the target model using the model instantiation method.

[0044] In this embodiment of the invention, based on the model instance task queue and resource status obtained by the operation monitoring tool, an asynchronous switching plan is generated using dynamic hot-switching technology, and a resource allocation and weight correction scheme is formulated.

[0045] Specifically, a runtime monitoring tool is used to obtain real-time information about running model instances, including the current model version, the type and number of incomplete tasks in the task queue, intermediate data cache, and the model's activity status. Based on the priority and execution time of tasks in the task queue, the timing for task completion of the current model instance is determined, and a current task runtime status report is generated.

[0046] Based on the model size configuration scheme and task runtime status reports, an asynchronous switching plan is constructed using dynamic hot-swapping technology. The time window for the switching process is obtained, including low-load periods for model instances and priority distribution of task queues. A resource allocation strategy for the switching period is generated using a task scheduling algorithm. The intermediate data and task context information that need to be retained during the switching process are determined, resulting in the required resource configuration scheme for the switching. A new model version is loaded through the asynchronous hot-swapping mechanism. The resource allocation strategy is invoked to load the parameters required by the model version into memory, and the new model version is initialized using a model instantiation method.

[0047] A switching verification tool is used to test the running status of the new model version. The model weight correction unit is used to assess the drift risk of model inference results during the model switching process based on the weight parameters of the current model version and the target model version, and to formulate a weight correction scheme for each layer of the model.

[0048] By simulating requests in a real task queue to invoke the new model version, key performance indicators (KPIs) during task execution are collected, including response time, prediction accuracy, inference speed, memory usage, and CPU and GPU utilization. By comparing the KPIs of the new model version obtained from the test with those of the old model version before the switch, anomalies in the new model version during the hot switch are identified, including performance degradation, task loss, or inconsistent states. This determines whether the new model version meets the performance requirements of the business tasks and records potential optimization opportunities during the hot switch. Based on real-time resource usage data during the hot switch, including memory usage, compute node utilization, and network bandwidth consumption, resource allocation strategies are adjusted, and model performance is retested. By comparing the new model's running status data before and after the test, the effectiveness of the adjustments is determined, and the final model version and running configuration scheme are recorded.

[0049] For example, a runtime monitoring tool is used to obtain real-time information about running model instances. It is found that the currently running model version is B1, with 300 incomplete tasks in the task queue, including 100 high-priority tasks (real-time loan approval requests) and 200 low-priority tasks (batch risk assessments). Intermediate data cache shows memory usage of 12GB, GPU utilization of 85%, and the model's activity status is high load. Based on the task priorities in the task queue, high-priority tasks take an average of 100 milliseconds each, while low-priority tasks take an average of 500 milliseconds each. It is determined that the task completion timing for the current model instance is as follows: high-priority tasks will complete within 10 seconds, while low-priority tasks will take approximately 100 seconds. The generated task runtime status report indicates that the current model instance will enter a low-load period within the next 10 seconds. Based on the new model scaling configuration scheme, such as reducing the number of parameters in the target model B2 by 20% and setting the runtime memory usage target at 8GB, combined with the task runtime status report, an asynchronous switching plan is constructed using dynamic hot-switching technology. By analyzing the resource allocation strategy generated by the task scheduling algorithm, the switching time window was determined to begin after high-priority tasks are completed, while low-priority tasks are paused, retaining the task context and approximately 2GB of intermediate data from unfinished tasks. The resource configuration scheme for the switch includes pre-allocating 6GB of memory and one GPU instance for initializing the target model. The new model version B2 is loaded via an asynchronous hot-swapping mechanism, the resource allocation strategy is invoked to load the required parameters of the target model into memory, and the new model version is initialized using a model instantiation method. The switch validation tool tests the runtime status of version B2. By evaluating the differences in the distribution of weight parameters between B1 and B2, it was found that the prediction accuracy may decrease by 2% due to weight drift. A weight correction scheme was formulated to adjust the weights to keep the prediction results of high-priority tasks consistent with B1. Simulating requests in a real task queue to invoke the new model B2 version, key performance indicators during task execution were collected. If the response time is reduced to 85 milliseconds / task, the prediction accuracy increases to 94%, the inference speed increases by 20%, memory usage decreases to 8GB, and GPU utilization decreases to 70%. By comparing these metrics with those of the old model B1 version before the switch, which had a response time of 100 milliseconds per task, a prediction accuracy of 92%, slower inference speed, 12GB of memory usage, and 85% GPU utilization, the performance improvements during the switch were identified, although network bandwidth consumption increased slightly. During the switch, based on real-time resource usage data, if memory usage fluctuated from 8GB to 10GB, the resource allocation strategy was adjusted, distributing low-priority tasks in the task queue to backup computing nodes, and the model performance was retested. After verifying the improved model stability, the final model version was recorded as B2, with a running configuration including 8GB of memory usage, a single GPU instance, and the optimized resource allocation strategy.

[0050] The model weight correction unit is used to assess the drift risk of model inference results during model switching based on the weight parameters of the current model version and the target model version, and to formulate a weight correction scheme for each layer of the model.

[0051] Based on the weight parameters of the current model version and the target model version, obtain the weight matrix of each layer of the neural network in the current version. The weight matrix of each layer of the target version of the neural network The parameters of each layer of the network in the model are vectorized to generate a set of layer weight vectors. and The weighted distribution similarity formula is used. Calculate the similarity of parameter distribution between the current version and the target version at each layer. And obtain the similarity set of all layers. ,in and This represents the value of the j-th parameter in the i-th layer. This represents the Euclidean norm of a vector. It is calculated using the weighted average formula. Calculate the weighted average of the similarities across all layers. ,in, is the weight importance coefficient of the i-th layer, learned through the contribution of each layer, and L represents the total number of layers in the model. A global similarity threshold is set. The weighted average With the set global similarity threshold In comparison, if the similarity is below the preset global similarity threshold... If a certain value is found, it is marked as a potential reasoning drift risk. If a drift risk exists, the reasoning result difference formula is used. Calculate the difference D of the inference results and determine whether it exceeds the preset drift tolerance threshold. and This represents the classification probability output for the k-th sample, where m is the total number of samples. If the difference in the inference result exceeds a preset drift tolerance threshold, then the classification probability is determined based on the weighted similarity set. Based on the difference D between the inference results and the weights, an incremental learning strategy is used to fine-tune the layers whose weight similarity is lower than a preset first similarity threshold, generating an optimized set of weight parameters. By loading the optimized target model version, a consistency test is run using simulation verification tools. The difference between the inference results of the optimized model and the current model is recalculated using the formula for the difference between the inference results. It is then determined whether the model has regressed to the drift tolerance range. If the verification is successful, the weight correction scheme is recorded and the model switch is completed.

[0052] For example, in a text classification task, there is a difference between the current model version C1 and the target model version C2. The weight matrix of each layer of the neural network in the current version is obtained. Weight matrix of each layer in the target version The weights of the first layer are vectorized to obtain... =[0.1,0.2,0.3] and =[0.15, 0.18, 0.35]. The weighted distribution similarity formula is used. The similarity of the first layer is calculated to be 0.98. After calculating the similarity for all layers, the similarity set S = [0.98, 0.85, 0.72] is obtained, where... and This represents the value of the j-th parameter in the i-th layer. The Euclidean norm of a vector. This calculates the similarity of parameter distributions between the current version and the target version at each layer using a weighted average formula. The importance coefficient of each layer is set to . Given [0.5, 0.3, 0.2], calculate the weighted average to obtain... =0.87, where, is the weight importance coefficient of the i-th layer, learned through the contribution of each layer, and L represents the total number of layers in the model. If the global similarity threshold is set to 0.9, since... =0.87 < 0.9, marked as potential inference drift risk. If drift risk exists, the predicted probability of the 3 samples is... =[0.8,0.6,0.7] and =[0.7,0.65,0.75], using the inference result difference formula The calculated discrepancy of the inference results was 0.05, of which... and This represents the classification probability output of the k-th sample, where m is the total number of samples. If the preset drift tolerance threshold is 0.04, since D = 0.05 > 0.04, the weight parameters need to be adjusted. The similarity of the third layer is 0.72, which is lower than the first similarity threshold of 0.8. For the third layer with a similarity lower than the first similarity threshold of 0.8, an incremental learning strategy is used to fine-tune the third layer. By adjusting the learning rate and training with incremental data, the optimized weight vector of the third layer is... =[0.28,0.35,0.42]. Load the optimized model version C2, run a consistency test using simulation verification tools, and recalculate the difference. If the predicted probability of the optimized model is =[0.78,0.62,0.72], the new inference result difference D is 0.02, then the verification is successful, the weight correction scheme is recorded and the model switch is completed.

[0053] By employing the technical means of this invention, the task queue and resource status of the current model are monitored, a low-load period is selected as the switching window, and a weight adjustment scheme is formulated to prevent the drift risk of model inference results during the model switching process, ensuring the stability of the results after the switch. The new model is asynchronously loaded to simulate real-world task performance testing. Once the performance meets the standards, the task queue is migrated, ensuring uninterrupted business operations throughout the process. This achieves seamless switching and verification, resulting in zero loss rate for model version switching tasks and improved consistency of inference results, thus guaranteeing the stability of business operations in high real-time scenarios.

[0054] As a preferred embodiment, the present invention further implements the above embodiments, and after deploying the current model of the business scenario, the method further includes step S16: S16. Based on the key indicator data of the current model during operation, issue early warnings for abnormal situations, and roll back or update the model when abnormal situations occur.

[0055] Preferably, step S16 specifically includes: S161. Monitor the key indicator data of the current model in real time during its operation; S1621. When the key indicator data exceeds the corresponding preset standard threshold, an abnormal situation is determined and an alarm is triggered. S163. When an abnormal situation occurs, determine whether there is a backup model; wherein, the backup model is the historical model corresponding to the historical model version with the highest stability and a similarity greater than a preset similarity threshold with the current model version. S164. When a backup model exists, switch to the backup model for operation; S165. When there is no backup model, trigger the retraining mechanism, use gradient descent and hyperparameter search algorithms to adjust the parameters of the current model, and generate a new model after repair.

[0056] It should be noted that during model operation, existing monitoring methods struggle to accurately detect performance degradation and resource anomalies, potentially leaving the model in a sub-healthy state for extended periods. This can lead to decreased inference speed, reduced accuracy, and even task failures. Model versions that fail to meet business requirements typically need retraining, but traditional retraining processes are time-consuming and inefficient, failing to meet the business's demand for rapid iteration.

[0057] To address the aforementioned issues, in this embodiment of the invention, based on real-time performance metrics data streams and anomaly detection results, historical versions with similarity greater than a preset second similarity threshold are selected, or a retraining mechanism is triggered to dynamically switch versions and roll back the model.

[0058] Specifically, operational monitoring tools are used to acquire key performance indicators (KPIs) during model execution, including response time, prediction accuracy, inference speed, memory usage, and CPU and GPU utilization. Data acquisition tools are used to periodically collect operational logs and system performance data, storing them in time-series format to obtain a real-time performance indicator data stream. Based on this real-time performance indicator data stream, an anomaly detection algorithm based on time-series analysis is loaded. Moving averages and time-series decomposition techniques are used to calculate the trends, periods, and outliers of the performance indicators. By comparing the upper and lower bounds of the performance indicators with anomaly thresholds, it is determined whether there are any abnormal conditions such as performance degradation, incorrect predictions, or abnormal resource usage.

[0059] If an anomaly is detected, a list of historical model versions with a similarity greater than a preset second similarity threshold is retrieved. The model version with the highest stability is selected, and the target model version to be rolled back is determined. Rollback task information is recorded. A dynamic version switching module loads the structure and parameter configuration of the target model version and calls the rollback function to complete the dynamic switch between the current model version and the target model version. The current task queue and intermediate data are migrated to the target model instance through an asynchronous transmission mechanism. The running status after the switch is recorded, and the new model instance running configuration is output. If the version management system cannot provide a historical model version that meets the requirements, the model retraining unit is used to retrain the model based on the anomaly detection results.

[0060] For example, during operation, key performance indicators of the current recommendation model are obtained through a monitoring tool: response time is 150 milliseconds, prediction accuracy is 90%, inference speed is 200 entries / second, memory usage is 70%, and GPU utilization is 85%. A data acquisition tool collects operation logs and system performance data every 5 seconds, storing this data in time-series format to form a real-time performance indicator data stream. Based on this real-time performance indicator data stream, an anomaly detection algorithm based on time-series analysis is loaded. The moving average method is used to calculate the short-term trend of the performance indicators, revealing that the average response time has increased to 180 milliseconds and memory usage has increased to 85% in the past minute. Time-series decomposition techniques are used to extract periodic changes, revealing a non-linear growth trend in memory usage. These performance indicators are compared with preset upper and lower bounds and anomaly thresholds to identify performance degradation and abnormal resource usage. Upon detecting anomalies, the version management system is invoked to retrieve a list of historical model versions with a similarity greater than the preset second similarity threshold of 0.8 to the current model version D1. Model version D2, with the highest similarity and best stability, is selected and marked as the target model version requiring rollback. Rollback task information, including intermediate data migration and resource adjustment requirements, is recorded. The structure and parameter configuration of the target model version D2 are loaded through the dynamic version switching module. D2's inference speed is 250 records / second, memory usage is 65%, and GPU utilization is 75%. The rollback function is invoked to switch between the current and target versions. An asynchronous transmission mechanism is used to migrate approximately 1GB of intermediate data from the current task queue and incomplete tasks to the target model instance, while resources are reallocated to ensure stable model operation after the switch. After the switch, the running status is recorded, with response time reduced to 120 milliseconds, memory usage reduced to 68%, and GPU utilization stabilized at 70%. The new model instance running configuration is output. If the version management system cannot provide a historical model version that meets the similarity threshold and stability requirements, a model retraining mechanism is triggered based on anomaly detection results. The current model is retrained and optimized based on the latest dataset to generate a new model version for deployment.

[0061] The model retraining unit is used to retrain the model based on anomaly detection results if the version management system cannot provide a historical model version that meets the requirements.

[0062] If the version management system cannot provide a historical model version that meets the requirements, a new dataset is loaded as input based on the abnormal data and runtime logs. The parameter optimization module is then invoked to generate new model parameters using gradient descent and hyperparameter search methods. The training framework is then invoked to run the training task, resulting in a repaired model version. Based on the repaired model version, the version management system loads the model structure and parameter configuration, generating a containerized deployment file. A distributed deployment tool is used to call the deployment file to redeploy the model instance. The testing module is then loaded to run the test dataset to verify model performance, collect new performance metrics, record the runtime status, determine whether the repaired model meets the runtime requirements, and output the final deployed model instance status.

[0063] For example, the real-time path optimization model experienced performance degradation, with response time increasing from the normal 200 milliseconds to 400 milliseconds, and prediction accuracy dropping from 98% to 85%. Since the version management system could not provide a historical model version that met the requirements, the system decided to generate a new model version based on abnormal data and runtime logs. By loading abnormal data from the past two weeks, 2 million data records containing path requests and actual execution results were allocated. Combined with current runtime logs, such as CPU usage at 90% and memory usage at 95%, a new training dataset was generated. The model parameters were adjusted using gradient descent-based optimization algorithms and hyperparameter search techniques, such as adjusting the learning rate from 0.001 to 0.0005, optimizing the network to 6 layers, and increasing the number of neurons per layer from 128 to 256. During the optimization process, the training loss was gradually reduced, ultimately resulting in a new set of model parameters. The training framework was invoked, and the training task was run using the new dataset. After 30 iterations, a repaired model version was generated, with training results showing that the loss function value decreased from 0.5 to 0.2. Based on the repaired model version, a version management system was used to load the new model structure and parameter configuration, generating corresponding containerized deployment files. These files included the optimized model binary files, required dependencies, and runtime environment configuration. Dependencies included PyTorch 1.12 and CUDA 11.6, and the runtime environment was configured as a single GPU instance with a memory limit of 16GB. The containerized deployment files were successfully redeployed using a distributed deployment tool, ensuring the optimized model started in the new environment. After deployment, a test module was loaded and a test dataset containing 50,000 real path requests was run to verify the performance of the repaired model. Test results showed that the model's response time decreased to 180 milliseconds, prediction accuracy improved to 96%, GPU utilization stabilized at 65% from 70%, and memory usage decreased from 95% to 80%. These new performance metrics were collected and the running status was recorded to determine if the repaired model met current operational requirements. Finally, the status of the deployed model instance was output, including its performance metrics, optimized configuration, and resource allocation, ensuring that the logistics path optimization model could once again meet the requirements for efficient operation.

[0064] By employing the technical means of this invention, during model operation, real-time performance monitoring and anomaly detection dynamically filter high-similarity historical versions for rapid rollback. If a historical version no longer meets the requirements, model retraining is triggered based on the anomaly detection results. This facilitates timely detection of performance degradation and resource anomalies in model operation, improving business execution success rates and ensuring system performance reliability and continuity. Furthermore, during model retraining, key data causing performance degradation is extracted based on anomaly detection results, generating targeted training datasets. Full-scale retraining is unnecessary; gradient descent and hyperparameter search algorithms are used to quickly adjust model parameters, shortening the training cycle. After training, containerized deployment files are automatically generated for rapid redeployment, and performance is verified using test datasets. This helps reduce retraining time and meets the needs of rapid business iteration.

[0065] As a preferred embodiment, the present invention is further implemented based on any of the above embodiments, and the method further includes steps S17 and S18: S17. Integrate the running status data of all historical model versions, use the cosine similarity algorithm to calculate the similarity between different model versions, and generate a version association map to show the optimization path between model versions; S18. Based on the version correlation graph, predict the future performance trend data of the model version, and generate model optimization suggestions based on the future performance data and key influencing factors.

[0066] In this embodiment of the invention, a performance trend chart is generated based on the running status data of real-time and historical log files and the evolution relationship of model versions, and the direction of future version optimization suggestions is predicted.

[0067] Specifically, a log parsing tool is used to load real-time and historical log files from each module to obtain runtime status data for deployed model versions, including runtime, response time, memory usage, computational resource allocation, and task success rate. Timestamp association technology is used to align and merge log data from different modules into a unified data table, resulting in a runtime status record throughout the model's lifecycle. Based on phased model performance trend curves, a version management system is used to load model version information, including model structure, parameters, performance, and configuration details. Cosine similarity is used to calculate the similarity between different versions, generating a version evolution relationship matrix. This matrix is ​​then converted into a version association graph to obtain the evolutionary relationships between model versions. Using the evolutionary relationships between model versions and the phased performance trend curves, a chart generation tool is used to generate performance change graphs for different stages, including response time trend graphs, accuracy change graphs, and resource usage curves. A 3D modeling tool is invoked to load model structure and parameter information, generating 3D models of different version models to demonstrate performance differences between them. By correlating the performance metrics and runtime status data of different versions, a list of key factors influencing performance changes is obtained. Based on the performance trend data of the model version, the ARIMA algorithm is used to train the model and predict its future performance trend. Based on the predicted future performance trend and a list of key factors, a list of optimization suggestions for the model version is generated, including parameter adjustment directions, structural optimization methods, and version upgrade strategies.

[0068] For example, to improve the service quality of the recommendation model, a log parsing tool is used to load real-time and historical log files of each module of the recommendation model to obtain the runtime status data of the deployed model versions. The log data for the current running version D3 shows a runtime of 200 hours, an average response time of 300 milliseconds, memory usage of 10GB, GPU utilization of 80%, and a task success rate of 95%. This log data is aligned with the log data of historical model versions D1 and D2, and merged into a unified data table using timestamp association technology to obtain the runtime status record of the model's entire lifecycle. Based on the recorded stage-by-stage model performance trend curves, if the response time changes to 400 milliseconds, 350 milliseconds, and 300 milliseconds in D1, D2, and D3, respectively, and the accuracy is 90%, 92%, and 94%, respectively, indicating a gradual improvement in resource usage stability, the version management system is invoked to load the model structure, parameters, performance, and configuration details for each version. The cosine similarity method is used to calculate the similarity between versions. If the similarity between D1 and D2 is 0.85, and the similarity between D2 and D3 is 0.90, a version evolution relationship matrix is ​​generated. The matrix was converted into a version correlation graph, showing the gradual optimization path and performance change trend of model versions D1 to D3. Using the correlation graph and staged performance trend curves, a chart generation tool was used to create a performance change graph of the recommendation model. The response time trend graph shows a gradual decrease in response time from D1 to D3, while the accuracy change graph shows a gradual improvement in performance. The resource usage curve shows that GPU utilization increased from 70% to 80%, and memory usage remained stable within 10GB. Simultaneously, a 3D modeling tool was used to load the structure and parameter information of each model version, generating a 3D model to show the details of the structural changes from D1 to D3, such as the increase in the number of hidden layers from 2 to 4 and the increase in the parameter scale from 50 million to 80 million. The performance differences between different model versions were then visually compared. By analyzing the version evolution relationship graph and performance change graph, and correlating version performance indicators with runtime data, a list of key performance influencing factors was identified. Increasing the number of hidden layers contributed the most to the improvement in accuracy, while optimizing memory management reduced response time. Based on performance trend data of model versions, the ARIMA algorithm is used for training to predict the performance trend of the model in the next two versions. For example, it is expected that the response time of D4 will further decrease to 250 milliseconds, the accuracy will increase to 96%, and the GPU utilization may increase to 85%. Based on the prediction results and the list of key factors, a list of optimization suggestions for future model versions is generated. For example, in version D4, it is recommended to add a hidden layer and optimize the choice of activation function to further improve accuracy, adjust the parameter distribution to reduce memory consumption, and formulate resource management strategies to balance GPU utilization and response time.

[0069] Furthermore, based on real-time key indicators and dynamic feedback mechanisms, extended configuration schemes are generated through pruning optimization and parallel processing, and model version evolution information is recorded.

[0070] Specifically, a runtime monitoring tool is used to acquire real-time key metrics of the new model version, including inference speed, task completion rate, and resource utilization efficiency. A log collection tool is used to record the runtime data flow, and a time window method is employed to preprocess the collected data, generating a standardized sequence of key metrics. A dynamic feedback mechanism is implemented, using rule-based logical judgment and anomaly detection algorithms to identify the current model version's runtime status. By calculating the deviation and stability of real-time metrics, the adaptation effect of the current version is determined to meet the scenario requirements, and a runtime status report is generated. By loading the computational node and memory requirements of the scenario, parallel processing and pruning optimization methods are used to generate an expanded configuration scheme, and changes in resource usage during the expansion process are recorded to obtain optimized model configuration data. Based on the optimized model configuration data, a closed-loop management approach is used to monitor the runtime status of the expanded model, loading real-time performance metrics and scenario adaptation results to verify whether the optimized model achieves the expected performance. Through the dynamic feedback mechanism, runtime data is written to the version management system, recording model version evolution information and updating the version path. A closed-loop management process is established to record and output the final runtime status report.

[0071] For example, a runtime monitoring tool is used to obtain real-time key metrics of model operation. Initial data shows that the model's inference speed is 800 requests per second, task completion rate is 90%, GPU utilization is 85%, and memory usage is 12GB. By calling a log collection tool, runtime data streams are recorded. Using a time window method, the collected data is preprocessed in 5-second windows to standardize the inference speed, task completion rate, and resource utilization into a key metric sequence of 0.8, 0.9, and 0.85, respectively. After loading a dynamic feedback mechanism, rule-based logical judgment and anomaly detection algorithms identify the current model version's runtime status. If the inference speed is lower than the scenario requirement of 1000 requests per second, inference performance is detected as substandard, and the task completion rate drops to 85%, showing a short-term fluctuation. By calculating the deviation of real-time metrics, the inference speed deviation is found to be 20%, indicating that the current version fails to fully meet the scenario requirements. A runtime status report is generated, recording the specific reasons for the current performance deficiency. Based on the scenario requirements of two GPU instances and 8GB of memory per node, a parallel processing approach was adopted to expand the computing resource configuration to two GPU nodes. Redundant weight parameters were reduced through pruning optimization, compressing the model size to 85% of the original number of parameters. Resource monitoring records during the expansion process showed that GPU utilization decreased to 70%, memory usage stabilized at 16GB, inference speed increased to 1200 requests per second, and task completion rate recovered to 98%. Optimized model configuration data was generated, recording resource changes and parameter pruning ratios. Based on the optimized model configuration data, a closed-loop management approach was used to monitor the running status of the expanded model, loading real-time performance metrics to verify whether the model performance met expectations. If the optimized inference speed reached 120% of the scenario requirements, the task completion rate was 98%, GPU utilization was 70%, and memory usage met the target allocation, the optimized model was verified to fully meet the requirements, and the optimization results were recorded. Through a dynamic feedback mechanism, the running data was written to the version management system, recording the optimization path of the model version, including the evolution information from single-node operation to dual-node parallelization, and from the initial number of parameters to the pruned parameter size, and updating the version path graph. Finally, a complete record of the closed-loop management process was established, and a final operational status report was output. The report showed that the model met the new scenario requirements, and summarized the resource-saving effect and performance improvement range of the optimization process, providing data support for subsequent version iterations.

[0072] By employing the technical means of this invention, real-time and historical operational data are analyzed to construct the model version evolution relationship and generate a performance trend chart. Combined with future performance prediction methods, this provides data support and directional guidance for model optimization. Real-time monitoring of new version operational metrics, and adjustments made through parallel processing, pruning, and other methods to update the version path if requirements are not met, forms a closed loop of monitoring, optimization, and verification. This avoids blind iteration, provides data support for subsequent optimizations, improves the accuracy of predicting new versions, and significantly enhances the model's full lifecycle optimization capabilities.

[0073] See Figure 2 This is a schematic diagram of the structure of a model management device provided in an embodiment of the present invention. The present invention also provides a model management device 10, comprising: Modular design module 11 is used to construct several independent management modules and their functional configuration information based on the model's full lifecycle management requirements using a modular design approach; The model configuration module 12 is used to obtain a model version that is compatible with the business scenario based on the requirements of the business scenario and the model feature data of the existing model version, and to determine and deploy the current model of the business scenario based on the model version. Model switching module 13 is used to determine a model switching window based on the task queue and resource status of the current model when preset model switching conditions are met; and, Based on the weight parameters of the current model and the target model to be switched, assess the drift risk of model inference results during model switching to formulate a weight adjustment scheme for each network layer of the model; and, In the model switching window, the current model is switched to the target model, and the current model after switching is corrected according to the weight correction scheme.

[0074] Preferably, the device 10 further includes: The model monitoring module is used to provide early warnings of abnormal situations based on key indicator data of the current model during operation, and to roll back or update the model when abnormal situations occur.

[0075] The final version and optimization module is used to integrate the running status data of all historical model versions, calculate the similarity between different model versions using the cosine similarity algorithm, generate a version association graph to show the optimization path between model versions, and predict the future performance trend data of model versions based on the version association graph, and generate model optimization suggestions based on the future performance data and key influencing factors.

[0076] It should be noted that the model management device provided in this embodiment of the invention is used to execute all the process steps of the model management method in the above embodiment. The working principles and beneficial effects of the two are one-to-one, so they will not be described again.

[0077] See Figure 3 This is a schematic diagram of the structure of a model management device provided in an embodiment of the present invention. The present invention also provides a model management device 20, including a processor 21, a memory 22, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the model management method as described in any of the above embodiments.

[0078] This invention also provides a computer-readable storage medium, which includes a stored computer program, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to execute the model management method as described in any of the above embodiments.

[0079] This invention also provides a computer program product, which includes a computer program or computer instructions. When the computer program or computer instructions are executed by a processor, they implement the model management method as described in any of the above embodiments.

[0080] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0081] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A model management method characterized by comprising: include: Based on the model's full lifecycle management requirements, a modular design approach is adopted to construct several independent management modules and their functional configuration information; Based on the needs of the business scenario and the model feature data of the existing model version, obtain the model version that is compatible with the business scenario, and determine and deploy the current model for the business scenario based on the model version. When the preset model switching conditions are met, the model switching window is determined based on the task queue and resource status of the current model; Based on the weight parameters of the current model and the target model to be switched, assess the drift risk of the model inference results during the model switching process, and formulate a weight correction scheme for each network layer of the model. In the model switching window, the current model is switched to the target model, and the current model after switching is corrected according to the weight correction scheme.

2. The model management method as described in claim 1, characterized in that, The management module includes a development module, a training module, a testing module, a deployment module, and an operation and maintenance module, which are used for the development, training, testing, deployment, and operation and maintenance of the management model, respectively. Based on the model's full lifecycle management requirements, a modular design approach is used to construct several independent management modules and their functional configuration information, including: Based on the model's full lifecycle management requirements, a modular design approach is adopted to construct each independent management module. Based on the functional requirements of each management module, the functional boundaries of each management module are determined, data transmission standards and functional protocols are unified, and an interface specification document for each management module is generated. Each management module is encapsulated using a pre-defined containerization tool, a containerized configuration file is built, and the configuration file is loaded by running the containerization tool to generate a module container image; The management module is deployed in a distributed manner by loading the module container image and running the instance using a preset deployment tool.

3. The model management method as described in claim 1, characterized in that, The step of obtaining a model version adapted to the business scenario based on the needs of the business scenario and the model feature data of existing model versions, and determining and deploying the current model for the business scenario based on the model version, includes: Obtain the requirement feature data of the business scenario and the model feature data of the existing model version; The demand feature data and the model feature data are normalized using a data normalization method to obtain normalized demand feature vectors and model feature vectors. Based on the normalized demand feature vector and model feature vector, the similarity is calculated using the cosine similarity formula. Based on the similarity, a model version that is compatible with the current business scenario is determined and denoted as the first model version; The version management system is used to load the runtime configuration file of the first model corresponding to the first model version, and the scale configuration of the model instance of the first model is obtained. Based on the runtime configuration file and the scale configuration, it is determined whether the model instance needs to be scaled. If a scaling adjustment is required, a model scaling adjustment suggestion is generated; wherein, the scaling adjustment suggestion includes whether to expand or shrink the current size; Based on the model size adjustment suggestions, the model instance is adjusted using model compression and expansion algorithms to generate the current model for the business scenario, and the current model is then deployed.

4. The model management method as described in claim 1, characterized in that, When the preset model switching conditions are met, the model switching window is determined based on the current model's task queue and resource status, including: When the preset model switching conditions are met, the task queue and resource status of the current model are obtained; wherein, the task queue includes high-priority tasks and low-priority tasks; The estimated completion time of the high-priority tasks in the task list is determined based on the resource status. Based on the estimated completion time, the completion time of the high-priority task is determined as the model switching window.

5. The model management method as described in claim 1, characterized in that, The step of assessing the drift risk of model inference results during model switching based on the weight parameters of the current model and the target model to be switched, in order to formulate a weight correction scheme for each network layer of the model, includes: Obtain the weight parameters of each network layer of the current model and the target model to be switched; Compare the similarity of the weight parameters of each network layer of the current model and the target model; Based on the similarity of the weight parameters, assess the risk of drift in the model inference results during model switching; Based on the drift risk, a weight adjustment scheme is formulated for each of the network layers; wherein the weight adjustment scheme includes an adjustment strategy for the weight parameters of each of the network layers.

6. The model management method as described in claim 1, characterized in that, The step of switching the current model to the target model in the model switching window includes: In the model switching window, the model version of the target model is loaded through an asynchronous hot-swapping mechanism; The resource allocation strategy is invoked to load the parameters required by the target model into memory, and the target model is initialized using the model instantiation method.

7. The model management method according to any one of claims 1 to 6, characterized in that, After deploying the current model for the aforementioned business scenario, the method further includes: Real-time monitoring of key indicator data during the operation of the current model; When the key indicator data exceeds the corresponding preset standard threshold, an abnormal situation is determined and an alarm is triggered; When an abnormal situation occurs, it is determined whether there is a backup model; wherein, the backup model is the historical model corresponding to the historical model version with the highest stability that has a similarity greater than a preset similarity threshold with the current model version. When a backup model exists, the system will switch to the backup model for operation. When no backup model is available, a retraining mechanism is triggered, employing gradient descent and hyperparameter search algorithms to adjust the parameters of the current model and generate a new, repaired model.

8. The model management method as described in claim 1, characterized in that, The method further includes: By integrating the runtime status data of all historical model versions, the cosine similarity algorithm is used to calculate the similarity between different model versions, and a version association map is generated to show the optimization paths between model versions. Based on the version correlation graph, predict the future performance trend data of the model version, and generate model optimization suggestions based on the future performance data and key influencing factors.

9. A model management device, characterized in that, include: The modular design module is used to construct several independent management modules and their functional configuration information based on the model's full lifecycle management requirements using a modular design approach. The model configuration module is used to obtain a model version that is compatible with the business scenario based on the requirements of the business scenario and the model feature data of the existing model version, and to determine and deploy the current model of the business scenario based on the model version. The model switching module is used to determine the model switching window based on the task queue and resource status of the current model when the preset model switching conditions are met. as well as, Based on the weight parameters of the current model and the target model to be switched, assess the drift risk of the model inference results during the model switching process, and formulate a weight correction scheme for each network layer of the model. as well as, In the model switching window, the current model is switched to the target model, and the current model after switching is corrected according to the weight correction scheme.

10. A model management device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor, when executing the computer program, implements the model management method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium is located to perform the model management method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes a computer program or computer instructions, which, when executed by a processor, implement the model management method as described in any one of claims 1 to 8.

Images