Multi-model system and model management method and apparatus therefor, and program product
Patent Information
- Application Number
- PCT/CN2025/084149
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-03-21
- Publication Date
- 2026-09-24
Smart Images
Figure CN2025084149_24092026_PF_FP_ABST
Abstract
Description
Multi-model systems and their model management methods, devices and program products Technical Field
[0001] This application relates to the field of model management, and in particular to multi-model systems and their model management methods, devices and program products. Background Technology
[0002] In the highly digitalized and automated transportation industry, real-time risk identification plays a crucial role in vehicle safety. Technological advancements have enabled the close integration of real-time data with artificial intelligence models, allowing for the real-time access to AI models to predict and assess potential risks to vehicles.
[0003] Currently, multi-model systems typically package multiple AI models directly into a JAR file. As the number of models increases and their complexity rises, model maintenance becomes cumbersome, version control becomes difficult, and system stability is affected. Technical issues
[0004] In view of this, embodiments of this application provide a multi-model system and its model management method, apparatus and program product to solve the problems in the prior art where model maintenance is troublesome, version control is difficult, and system stability is affected as the number and complexity of models increase. Technical solutions
[0005] To solve the above-mentioned technical problems, the technical solution adopted in the embodiments of this application is as follows:
[0006] A first aspect of this application provides a model management method for a multi-model system, the method comprising:
[0007] Package the different versions of the model in the multi-model system into separate compressed files;
[0008] Create a GIT branch and commit each of the compressed files to the corresponding GIT branch;
[0009] The compressed file of the model is stored in the access location of the Flink cluster via the Git branch;
[0010] The process involves identifying the model to be loaded, decompressing the model to be loaded, determining the class file of the model to be loaded, creating a class loader for the model to be loaded, dynamically loading and registering instances of the class file of the model to be loaded through the class loader, and processing data based on the registered instances.
[0011] In conjunction with the first aspect, in a first possible implementation of the first aspect, after dynamically loading and registering instances of the class file of the model to be loaded through the class loader, the method further includes:
[0012] When an instruction is received to update an already loaded model in the Flink cluster to a new model, the instance of the already loaded model is removed from the model manager, and the class loader of the already loaded model is unloaded.
[0013] A class loader for the new model is created, and the class file of the new model is dynamically loaded and instances are registered through the class loader.
[0014] In conjunction with the first aspect, in a second possible implementation of the first aspect, different versions of the models in the multi-model system are packaged into independent compressed files, including:
[0015] The model architecture file, preprocessing file, weight file, and configuration file of each model in different versions of the multi-model system are determined.
[0016] The model architecture files, preprocessing files, weight files, and configuration files of each model are stored in their respective specific directory structures.
[0017] Based on the directory structure, the model architecture file, preprocessing file, weight file, and configuration file of the same model are combined into a single compressed file.
[0018] In conjunction with the first aspect, in the third possible implementation of the first aspect, a GIT branch is created, and each of the compressed files is committed to the corresponding GIT branch, including:
[0019] Determine the warehouse corresponding to the model;
[0020] Create a Git branch corresponding to the model in the repository;
[0021] Submit the compressed file of the model to the GIT branch.
[0022] In conjunction with the first aspect, in the fourth possible implementation of the first aspect, storing the compressed file of the model to the access location of the Flink cluster via the GIT branch includes:
[0023] Determine the GIT branch corresponding to the model;
[0024] The compressed file of the model is obtained through the Git branch;
[0025] The compressed file is transferred to the access location of the Flink cluster.
[0026] In conjunction with the first aspect, in the fifth possible implementation of the first aspect, the model to be loaded is determined, and the class file of the model to be loaded is decompressed, including:
[0027] Obtain preset configuration information to determine the path information of the model to be loaded;
[0028] The compressed file of the model to be loaded is determined based on the path information;
[0029] Extract the compressed file to the local directory of the Flink Task Manager;
[0030] Traverse the local directory of the model to be loaded to determine the class file of the model to be loaded.
[0031] In conjunction with any one of the first to fifth possible implementations of the first aspect, in the sixth possible implementation of the first aspect, dynamic class loading and instance registration of the class file of the model to be loaded is performed through the class loader, including:
[0032] The class file of the model to be loaded is loaded by the class loader;
[0033] Model instances are determined through reflection or through construction methods;
[0034] Register the instance to the model manager.
[0035] A second aspect of this application provides a model management apparatus for a multi-model system, the apparatus comprising:
[0036] The compression unit is used to package different versions of the model in the multi-model system into independent compressed files;
[0037] The branch creation unit is used to create GIT branches and commit each of the compressed files to the corresponding GIT branches.
[0038] A storage unit is used to store the compressed file of the model to the access location of the Flink cluster via the GIT branch;
[0039] The loading and registration unit is used to determine the model to be loaded, decompress the model to be loaded, determine the class file of the model to be loaded, create a class loader for the model to be loaded, perform dynamic class loading and instance registration on the class file of the model to be loaded through the class loader, and perform data processing based on the registered instances.
[0040] In conjunction with the second aspect, in a first possible implementation of the second aspect, the apparatus further includes:
[0041] The update unit is used to delete the instance of the loaded model from the model manager and unload the class loader of the loaded model when it receives an instruction to update the loaded model in the Flink cluster to a new model.
[0042] The new loading unit is used to create a class loader for the new model, and to perform dynamic class loading and instance registration of the class files of the new model through the class loader.
[0043] In conjunction with the second aspect, in a second possible implementation of the second aspect, the compression unit includes:
[0044] The file determination subunit is used to determine the model architecture file, preprocessing file, weight file and configuration file of each model in different versions of the model in the multi-model system;
[0045] The storage subunit is used to store the model architecture files, preprocessing files, weight files and configuration files of each model into their respective specific directory structures;
[0046] The combination subunit is used to combine the model architecture file, preprocessing file, weight file and configuration file of the same model into a single compressed file according to the directory structure.
[0047] In conjunction with the second aspect, in a third possible implementation of the second aspect, the branch creation subunit includes:
[0048] The warehouse determination sub-unit is used to determine the warehouse corresponding to the model;
[0049] GIT branch creation sub-units are used to create GIT branches corresponding to the models in the repository;
[0050] Submit a subunit, used to submit the compressed file of the model to the GIT branch.
[0051] In conjunction with the second aspect, in a fourth possible implementation of the second aspect, the storage unit includes:
[0052] GIT branch determination subunit, used to determine the GIT branch corresponding to the model;
[0053] The compressed file acquisition subunit is used to acquire the compressed file of the model through the GIT branch;
[0054] The transmission subunit is used to transmit the compressed file to the access location of the Flink cluster.
[0055] In conjunction with the second aspect, in the fifth possible implementation of the second aspect, the loading registration unit includes:
[0056] The path information acquisition subunit is used to acquire preset configuration information to determine the path information of the model to be loaded;
[0057] The compressed file determination subunit is used to determine the compressed file of the model to be loaded based on the path information;
[0058] The decompression subunit is used to decompress the compressed file to the local directory of the Flink task manager;
[0059] Traverse sub-units to traverse the local directory of the model to be loaded and determine the class file of the model to be loaded.
[0060] In conjunction with any one of the second to fifth possible implementations of the second aspect, in the sixth possible implementation of the second aspect, the loading registration unit includes:
[0061] A loading subunit is used to load the class file of the model to be loaded through the class loader;
[0062] Construct sub-units to determine model instances via reflection or a constructor;
[0063] The registration subunit is used to register the instance to the model manager.
[0064] A third aspect of this application provides a multi-model system including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the multi-model system implements the method as described in any of the first aspects.
[0065] A fourth aspect of this application provides a computer program product that, when run on a computer, causes the computer to execute the methods described in the first aspect or its various implementations.
[0066] A fifth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method as described in any of the first aspects.
[0067] A sixth aspect of this application provides a chip for implementing the methods in the various implementations of the first aspect described above. Specifically, the chip includes a processor for calling and running a computer program from a memory, causing a device equipped with the chip to perform the methods as described in the first aspect or its various implementations. Beneficial effects
[0068] The beneficial effects of this application's embodiments compared to existing technologies are as follows: This application's embodiments package different versions of models in a multi-model system into independent compressed files, with each compressed file representing an independent model. This makes model management clearer, facilitates the addition, deletion, and updating of models, and reduces the complexity of searching and modifying a large number of models. By creating Git branches and committing each compressed file to its corresponding Git branch, the development and modification of models are independently tracked and managed, facilitating version control, backtracking, and parallel development, thus improving the maintainability and robustness of the system. By storing the compressed model files in the Flink cluster's access location through Git branches, decompressing the models to be loaded to determine class files, and creating class loaders for the models to be loaded for dynamic class loading, the independence of model operation is enhanced, conflicts between models are reduced, and the system operation is more stable. Attached Figure Description
[0069] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0070] Figure 1 is a schematic diagram illustrating the implementation flow of a model management method for a multi-model system provided in an embodiment of this application;
[0071] Figure 2 is a schematic diagram of the implementation process of a model packaging method provided in an embodiment of this application;
[0072] Figure 3 is a schematic diagram of the implementation process of a branch creation method provided in an embodiment of this application;
[0073] Figure 4 is a schematic diagram of the implementation process of a model dynamic loading method provided in an embodiment of this application;
[0074] Figure 5 is a schematic diagram of a model management device for a multi-model system provided in an embodiment of this application;
[0075] Figure 6 is a schematic diagram of a multi-model system provided in an embodiment of this application. Embodiments of the present invention
[0076] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.
[0077] To illustrate the technical solution described in this application, specific embodiments are provided below.
[0078] In the highly digitalized and automated transportation industry, real-time risk identification is crucial for vehicle safety. Real-time risk identification enables the timely detection of potential hazards, allowing for appropriate measures to avoid or reduce accidents. Technological advancements have enabled the close integration of real-time data with artificial intelligence models, allowing for real-time access to AI models to predict and assess potential vehicle risks. This integration not only improves the accuracy of risk identification but also enhances the system's responsiveness.
[0079] However, current multi-model systems typically package multiple AI models directly into a JAR file, which has the following significant drawbacks:
[0080] 1. Severe Model Coupling: As the number and complexity of models increase, the project size expands, with multiple models tightly coupled together. This tight coupling makes management and maintenance extremely difficult, as modifications to any one model can affect the normal operation of other models. This coupling not only increases the complexity of development and maintenance but may also lead to a decrease in the overall stability of the system.
[0081] 2. High Resource Consumption: The massive project files not only increase the burden on the code repository but also make deployment and update processes time-consuming and inefficient. Since all models are packaged in a single JAR file, each update or deployment requires processing the entire file, consuming significant storage space and increasing network transmission time and costs. This high resource consumption further exacerbates the difficulty of system maintenance.
[0082] 3. Version control difficulties: When updating a model or releasing a new model, the entire project needs to be rebuilt and deployed. This overall update approach makes fine-grained model version control difficult because each update requires repackaging the entire JAR file. This not only increases the complexity of version management but may also make version rollback and comparison difficult, thus affecting the stability and reliability of the system.
[0083] 4. System Stability Risk: Frequent system updates may cause system interruptions, affecting the continuity and stability of real-time risk identification. Since each update requires system shutdown or restart, this can lead to service interruptions, consequently impacting vehicle safety monitoring. This system stability risk not only degrades user experience but may also pose serious security threats.
[0084] To address the aforementioned issues, this application proposes a multi-model model management method. This method packages different versions of models into independent compressed files, manages model files using Git branches, and integrates a Flink cluster for model loading and updates. This achieves efficient management and maintenance of the multi-model system, improving the flexibility of model updates and the stability of the system. As shown in Figure 1, the implementation process of this method includes:
[0085] In S101, different versions of the model in the multi-model system are packaged into independent compressed files.
[0086] The multi-model system in this application embodiment can include multiple models of different types, and each type of model can include one or more different versions. For example, the multi-model system includes model A and model B, model A includes version V1 and version V2, and model B includes version V1. Alternatively, the multi-model system can be a model that includes multiple different versions of the same model. For example, the multi-model system includes model A, and model A includes version V1, version V2, and version V3, etc.
[0087] For different versions or types of models, each model includes specific model files such as model architecture files, preprocessing files, weight files, and configuration files. The model architecture file defines the structure of the model, such as the number of layers in the neural network and the number of neurons in each layer; the preprocessing file contains code or configuration for preprocessing the input data, such as data normalization and standardization operations; the weight file stores the parameters after model training; and the configuration file contains parameter settings for model training and runtime, such as learning rate and batch size.
[0088] The specific implementation process of packaging different versions of the model into independent compressed files can be shown in Figure 2, including:
[0089] In S201, the model architecture file, preprocessing file, weight file, and configuration file of each model in different versions of the model in the multi-model system are determined.
[0090] For the same model with different versions, the model architecture file, preprocessing method, and weight parameters in the weight file may differ for each version. It can receive user configuration data or determine the model architecture file, preprocessing file, weight file, and configuration file based on the file names.
[0091] In S202, the model architecture files, preprocessing files, weight files, and configuration files of each model are stored in specific directory structures.
[0092] A specific directory structure can include directories corresponding to each file, storing the files in their respective directories. For example, the directory structure of model_V1.0 includes a structure directory, a preprocessing directory, a weights directory, and a configuration directory, where files can be stored. For instance, the directory structure of model_V1.0 can be represented as follows:
[0093] model_v1.0 /
[0094] ├── architecture /
[0095] │ └── model.py
[0096] ├── preprocessing /
[0097] │ └── preprocess.py
[0098] ├── weights /
[0099] │ └── weights.h5
[0100] └── config /
[0101] └── config.json
[0102] In the above directory structure, model_v1.0 is the directory for model version 1.0, the architecture / directory stores model architecture files, the preprocessing / directory stores preprocessing files, the weights / directory stores weight files, and the config / directory stores configuration files.
[0103] In S203, the model architecture file, preprocessing file, weight file, and configuration file of the same model are combined into a single compressed file according to the directory structure.
[0104] For model files under the same version, compression tools (such as WinRAR, 7-Zip, etc.) can be used to compress the model file model_v1.0 into a model_v1.0.zip file according to the set directory structure. This facilitates model storage, transmission, and management, and also reduces model file redundancy.
[0105] Since each model exists as an independent ZIP file, the overall size of the project can be effectively reduced. Only the necessary models are loaded during operation, which helps save system resources.
[0106] In S102, create a GIT branch and commit each of the compressed files to the corresponding GIT branch.
[0107] In version control systems (such as Git), you can create a separate repository for each model. For example, you can create a repository for a security detection model. Within that repository, you can create a separate Git branch for each model version. For instance, for model version 1.0, you could create a branch named `model_v1.0`; and for model version 2.0, you could create a branch named `model_v2.0`.
[0108] You can submit the compressed file of each model to the corresponding Git branch. When submitting, you can write a commit message explaining the content and purpose of the submission. For example, the commit message could be "Submit compressed file of model version 1.0".
[0109] Managing model files through Git branches makes version control and rollback operations convenient, and also facilitates collaborative development within a team.
[0110] In S103, the compressed file of the model is stored in the access location of the Flink cluster via the GIT branch.
[0111] Flink Cluster is a distributed computing framework used to process large-scale data. Within a Flink Cluster, model files are needed for model loading and inference. The compressed model files are stored in the Flink Cluster's access location via a Git branch. The specific steps are shown in Figure 3, including:
[0112] In S301, the GIT branch corresponding to the model is determined.
[0113] Git branches are branches determined by the Git system. The corresponding Git branch for each model can be determined based on the mapping between models and Git branches. For example, if model version 1.0 needs to be loaded, the corresponding Git branch is determined to be model_v1.0.
[0114] Version control via Git branches can effectively improve the convenience of model modification and tracking, facilitate rapid model rollback, and improve development and maintenance efficiency.
[0115] In S302, the compressed file of the model is obtained through the GIT branch.
[0116] The compressed file of the model can be obtained from the determined Git branch using the Git command.
[0117] For example, you can use the `git clone` command to clone the code of the `model_v1.0` branch to your local machine, or use the `git pull` command to pull the latest model files from a remote repository.
[0118] In S303, the compressed file is transmitted to the access location of the Flink cluster.
[0119] The access location of the Flink cluster is a preset location that can be accessed by the Flink cluster.
[0120] For example, compressed files can be uploaded to a shared storage directory within the Flink cluster, or uploaded to the cluster using Flink's file upload tool. The Flink cluster provides convenient access to model files for model loading and inference operations.
[0121] In S104, the model to be loaded is determined, the model to be loaded is decompressed, the class file of the model to be loaded is determined, a class loader of the model to be loaded is created, the class loader is used to dynamically load the class file of the model to be loaded and register instances, and data processing is performed based on the registered instances.
[0122] When using a model through a Flink cluster, it's necessary to determine the model to be loaded. This can be done through configuration information, including configuration files or command-line arguments, to determine the path to the model. Configuration information is typically stored in configuration files, such as .yaml or .json files. The configuration file specifies the name, version, path, and other information of the model to be loaded.
[0123] After determining the model to be loaded, the compressed file of the model to be loaded can be obtained according to the path information. If the path of model version 1.0 is specified as / models / model_v1.0.zip in the configuration file, then the compressed file to be loaded is determined to be / models / model_v1.0.zip.
[0124] Unzipping the compressed file of the model to be loaded will reveal the model's class file. The class file is the core of the model, containing its definition and implementation. For example, for a Python implementation of the model, the class file might be a .py file, which defines the model's classes and methods.
[0125] Extract the selected compressed file to a local directory in the Flink Task Manager. For example, you can use an unzipping tool (such as unzip) to extract / models / model_v1.0.zip to the / flink / taskmgr / models directory.
[0126] After decompressing the model's compressed file, you can use a file traversal tool (such as os.walk) to find the class files included in the model to be loaded. For example, for a Python implementation of a model, the class file might be a .py file that defines the model's classes and methods. By traversing the decompressed directory, you can find these class files.
[0127] To enhance the system's flexibility and scalability, embodiments of this application can create a custom class loader for the model to be loaded. The class loader loads the class file and converts it into executable code.
[0128] Dynamic loading and unloading of class files via class loaders—that is, loading or unloading class files at runtime instead of compile time—allows for more flexible loading of different model classes without recompiling the entire program. This reduces the number of system restarts or redeployments, lowers the risk of system interruption, and improves system stability and reliability. Furthermore, using custom class loaders to isolate models effectively reduces conflicts between them, enhancing system robustness.
[0129] After loading the class file, you need to create instances of the model and register them with the model manager. The model manager is a component responsible for managing model instances; it can be an in-memory data structure (such as a dictionary or list) or a table in a database. After registering model instances, the model manager can easily manage and schedule them for model inference and data processing.
[0130] For example, for a real-time risk identification model, vehicle data can be received through a real-time data processing framework (such as the Flink framework). Based on preset rules or configuration information, a model instance for risk identification can be determined, the vehicle data can be passed to the model's preprocessing module for preprocessing, the model can then be called to perform risk identification, the risk identification result can be passed to the post-processing module, and finally the risk identification result can be output.
[0131] In addition, after the model loading and registration are completed, if it is necessary to update to a new model, such as when receiving an instruction to update the loaded model in the Flink cluster to a new model, the instance of the loaded model can be deleted from the model manager, the class loader of the loaded model can be unloaded, and a new class loader for the new model can be created. The class loader can then dynamically load and register the class files of the new model, thereby enabling dynamic switching between different versions of the model.
[0132] Figure 4 is a schematic diagram of a model loading process provided in an embodiment of this application, which is described in detail below:
[0133] Steps 1-4: Model loading request and download
[0134] 1. The Flink application requests and loads the model.
[0135] The Flink application sends a request to the Flink Task Manager to load the model, which is then used for risk prediction on new data streams.
[0136] 2. The Flink Task Manager sends a request to the model storage to obtain the path to the model ZIP file.
[0137] When the Flink Task Manager receives a request to load a model, it first needs to obtain the model's ZIP file path. This path may be stored in a configuration file or can be obtained by querying the model name. A request to retrieve the model's ZIP file path can be sent to ModelStorage.
[0138] 3. The model storage returns the ZIP file path to the Flink Task Manager.
[0139] ModelStorage provides the path to the model ZIP file, which may be stored in a distributed file system.
[0140] 4. Use Flink Task Manager to download and extract the ZIP file to your local machine.
[0141] The Flink Task Manager downloads the ZIP file from the model storage based on the provided path and extracts it to the local directory for subsequent loading of model class files.
[0142] Steps 5-8 are used to create a custom class loader.
[0143] 5. The Flink Task Manager requests the Class Loader Manager to create a custom class loader.
[0144] To load the model's class files, the Flink Task Manager can create a custom class loader to achieve class loading isolation.
[0145] 6. The ClassLoaderManager creates custom class loaders using custom class loaders.
[0146] The ClassLoaderManager creates custom class loaders from custom class loaders, which will be used to load the class files of the model.
[0147] 7. Custom class loaders return custom class loaders to the class loader manager.
[0148] After the custom class loader is determined, it is returned to the class loader manager.
[0149] 8. The Class Loader Manager returns a custom class loader to the Flink Task Manager.
[0150] The Flink Task Manager returns the received custom class loader to the Flink Task Manager for later use.
[0151] Steps 9-11 are used for dynamic class loading and instance registration.
[0152] 9. The Flink Task Manager traverses the unzipped directory and loads the .class files.
[0153] The Flink Task Manager iterates through the unzipped model directory and loads the .class files within it.
[0154] 10. Use a custom class loader to load class files and send them to the model instance manager.
[0155] The Model Instance Manager creates model instances using models that have loaded class files.
[0156] 11. The Model Instance Manager returns model instances to the custom class loader.
[0157] The model instance manager returns the created model instance to the custom class loader.
[0158] Steps 12-14 are used for model instance registration and loading.
[0159] 12. The custom class manager returns model instances to the Flink task manager.
[0160] The Flink Task Manager returns the received model instance to the Flink Task Manager.
[0161] 13. Register model instances to the model manager using the Flink Task Manager.
[0162] To facilitate management and reuse, the Flink Task Manager registers model instances with the Model Manager.
[0163] 14. The Flink Task Manager returns a model loading completion message to the Flink application.
[0164] When the Flink application receives a message that the model has finished loading, the model is ready for data processing and risk prediction.
[0165] Through the steps described above, the Flink application can dynamically load and register model instances, enabling risk prediction of real-time data streams. This dynamic loading mechanism not only improves the flexibility of model management but also enhances the system's scalability and stability.
[0166] It is understandable that in the above interaction process, the Flink Task Manager, Model Memory, Class Loader, Custom Class Loader, and Model Instance Manager are modules determined by their functions and can be configured on one or more servers in a multi-model management system.
[0167] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0168] Figure 5 is a schematic diagram of a model management device for a multi-model system provided in an embodiment of this application. The device includes:
[0169] Compression unit 501 is used to package different versions of the model in the multi-model system into independent compressed files;
[0170] Branch creation unit 502 is used to create GIT branches and commit each of the compressed files to the corresponding GIT branches;
[0171] Storage unit 503 is used to store the compressed file of the model to the access location of the Flink cluster through the GIT branch;
[0172] The loading registration unit 504 is used to determine the model to be loaded, decompress the model to be loaded, determine the class file of the model to be loaded, create a class loader for the model to be loaded, perform dynamic class loading and instance registration on the class file of the model to be loaded through the class loader, and perform data processing based on the registered instances.
[0173] The model management device of the multi-model system shown in Figure 5 corresponds to the model management method of the multi-model system shown in Figure 1.
[0174] Figure 6 is a schematic diagram of a multi-model system provided in an embodiment of this application. As shown in Figure 6, the multi-model system 6 of this embodiment includes: a processor 60, a memory 61, and a computer program 62 stored in the memory 61 and executable on the processor 60, such as a model management program for a multi-model system. When the processor 60 executes the computer program 62, it implements the steps in the model management method embodiments of the various multi-model systems described above. Alternatively, when the processor 60 executes the computer program 62, it implements the functions of each module / unit in the various device embodiments described above.
[0175] For example, the computer program 62 may be divided into one or more modules / units, which are stored in the memory 61 and executed by the processor 60 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 62 in the multi-model system 6.
[0176] The multi-model system may include, but is not limited to, a processor 60 and a memory 61. Those skilled in the art will understand that Figure 6 is merely an example of a multi-model system 6 and does not constitute a limitation on the multi-model system 6. It may include more or fewer components than illustrated, or combine certain components, or use different components. For example, the multi-model system may also include input / output devices, network access devices, buses, etc.
[0177] The processor 60 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.
[0178] The memory 61 can be an internal storage unit of the multi-model system 6, such as a hard disk or memory of the multi-model system 6. The memory 61 can also be an external storage device of the multi-model system 6, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the multi-model system 6. Furthermore, the memory 61 can include both internal storage units and external storage devices of the multi-model system 6. The memory 61 is used to store the computer program and other programs and data required by the multi-model system. The memory 61 can also be used to temporarily store data that has been output or will be output.
[0179] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0180] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0181] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0182] In the embodiments provided in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.
[0183] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0184] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0185] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by hardware related to computer program instructions. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.
[0186] In addition, this application also provides a computer program product that, when run on a computer, causes the computer to execute the methods in the above-described implementations.
[0187] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A model management method for a multi-model system, characterized in that, The method includes: Package the different versions of the model in the multi-model system into separate compressed files; Create a GIT branch and commit each of the compressed files to the corresponding GIT branch; The compressed file of the model is stored in the access location of the Flink cluster via the Git branch; The process involves identifying the model to be loaded, decompressing the model to be loaded, determining the class file of the model to be loaded, creating a class loader for the model to be loaded, dynamically loading and registering instances of the class file of the model to be loaded through the class loader, and processing data based on the registered instances.
2. The method according to claim 1, characterized in that, After dynamically loading and registering instances of the class files of the model to be loaded using the class loader, the method further includes: When an instruction is received to update an already loaded model in the Flink cluster to a new model, the instance of the already loaded model is removed from the model manager, and the class loader of the already loaded model is unloaded. A class loader for the new model is created, and the class file of the new model is dynamically loaded and instances are registered through the class loader.
3. The method according to claim 1, characterized in that, The different versions of the models in the multi-model system are packaged into separate compressed files, including: The model architecture file, preprocessing file, weight file, and configuration file of each model in different versions of the multi-model system are determined. The model architecture files, preprocessing files, weight files, and configuration files of each model are stored in their respective specific directory structures. Based on the directory structure, the model architecture file, preprocessing file, weight file, and configuration file of the same model are combined into a single compressed file.
4. The method according to claim 1, characterized in that, Create a Git branch, and commit each of the compressed files to the corresponding Git branch, including: Determine the warehouse corresponding to the model; Create a Git branch corresponding to the model in the repository; Submit the compressed file of the model to the GIT branch.
5. The method according to claim 1, characterized in that, The compressed file of the model is stored in the Flink cluster's access location via the Git branch, including: Determine the GIT branch corresponding to the model; The compressed file of the model is obtained through the Git branch; The compressed file is transferred to the access location of the Flink cluster.
6. The method according to claim 1, characterized in that, Determine the model to be loaded, decompress the model to be loaded, and determine the class file of the model to be loaded, including: Obtain preset configuration information to determine the path information of the model to be loaded; The compressed file of the model to be loaded is determined based on the path information; Extract the compressed file to the local directory of the Flink Task Manager; Traverse the local directory of the model to be loaded to determine the class file of the model to be loaded.
7. The method according to any one of claims 1-6, characterized in that, Dynamic class loading and instance registration of the class files of the model to be loaded are performed through the class loader, including: The class file of the model to be loaded is loaded by the class loader; Model instances are determined through reflection or through construction methods; Register the instance to the model manager.
8. A model management device for a multi-model system, characterized in that, The device includes: The compression unit is used to package different versions of the model in the multi-model system into independent compressed files; The branch creation unit is used to create GIT branches and commit each of the compressed files to the corresponding GIT branches. A storage unit is used to store the compressed file of the model to the access location of the Flink cluster via the GIT branch; The loading and registration unit is used to determine the model to be loaded, decompress the model to be loaded, determine the class file of the model to be loaded, create a class loader for the model to be loaded, perform dynamic class loading and instance registration on the class file of the model to be loaded through the class loader, and perform data processing based on the registered instances.
9. A multi-model system, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it causes the multi-model system to implement the method as described in any one of claims 1-7.
10. A computer program product comprising computer program instructions, characterized in that, When the computer program is run, the method as described in any one of claims 1-7 is performed.