Model management and control method and device, electronic equipment and storage medium

Abstract

The invention discloses a model management and control method and device, electronic equipment and a storage medium, and belongs to the technical field of large models.In the method, at least one piece of obtained model library information is displayed in response to a model obtaining condition, and each piece of model library information comprises a business function achieved by a model in a model library; in response to a selection operation on any piece of model library information, at least one piece of branch information of the corresponding model library is displayed, each piece of branch information is used for describing characteristics of a group of models in the model library when a service function is realized, and each group of models comprises a training model and an intermediate model after format conversion of the training model; and displaying the model information of the corresponding group model in the model library in response to the selection operation of any branch information for the equipment model after the equipment deployment of the intermediate model. Therefore, the training model, the associated intermediate model and the associated equipment model are stored as a group of models, so that a group of models associated with any model can be found conveniently, and the models are easy to control.

Description

Technical Field

[0001] The present application relates to the field of large model technology, and in particular to a model management method, device, electronic device and storage medium. Background Art

[0002] With the development of artificial intelligence (AI), model complexity continues to increase, and model file sizes are also increasing, from tens of GB to hundreds of GB or even larger. Currently, whoever develops the model is responsible for managing it. For scenarios that require frequent iteration, rapid deployment, and large-scale storage, managing a large number of models becomes a challenge. Summary of the Invention

[0003] The embodiments of the present application provide a model management method, device, electronic device and storage medium to provide a solution for managing large models.

[0004] In a first aspect, an embodiment of the present application provides a model management method, including:

[0005] In response to the model acquisition condition, display at least one piece of model library information acquired, wherein each piece of model library information includes a business function implemented by a model in the model library;

[0006] In response to a selection operation on any model library information, at least one branch information of the corresponding model library is displayed, wherein each branch information is used to describe the characteristics of a group of models in the model library when implementing a corresponding business function, and each group of models includes a training model, an intermediate model after format conversion of the training model, and a device model after the intermediate model is deployed on a device;

[0007] In response to a selection operation on any branch information, model information of a corresponding group of models in the model library is displayed.

[0008] In some embodiments, in response to the model acquisition condition, displaying at least one acquired model library information includes:

[0009] In response to the model retrieval information, display at least one model library information that matches the model retrieval information; or,

[0010] In response to the arrival of the model push opportunity, the at least one piece of model library information is displayed.

[0011] In some embodiments, after displaying the model information of the corresponding group of models in the model library, the method further includes:

[0012] In response to a download request for any target model, the target model is downloaded, where the target model is any model in a corresponding group of models in the model library.

[0013] In some embodiments, the target model includes a plurality of model files, each model file belonging to the first type of file or the second type of file; and

[0014] Download the target model, including:

[0015] Sending a download request for the target model to a first server, triggering the first server to download a model file of the target model belonging to the first category of files from a first storage cluster;

[0016] A download request for the target model is sent to a second server, triggering the second server to download a model file of the target model belonging to the second category of files from a second storage cluster, where the storage performance of the second storage cluster is lower than that of the first storage cluster.

[0017] In some embodiments, when the size of any model file exceeds a preset size, the model file is divided into multiple sub-files and stored in the first storage cluster, and

[0018] The first server downloads the multiple sub-files in parallel from the first storage cluster.

[0019] In some embodiments, the target model is stored according to the following steps:

[0020] In response to the model upload operation, determining upload information, the upload information including a plurality of model files of the target model and a branch identifier, the branch identifier being used to indicate the branch to which the target model belongs;

[0021] For any model file, if the model file belongs to the first category of files, sending an upload request for the model file to the first server, wherein the upload request includes the branch identifier, triggering the first server to store the model file in the first storage cluster;

[0022] If the model file belongs to the second type of file, an upload request for the model file is sent to the second server, where the upload request includes the branch identifier, triggering the second server to store the model file in the second storage cluster.

[0023] In some embodiments, if the model file belongs to the first type of file, the method further includes:

[0024] Identify the model type corresponding to the model file;

[0025] According to the branch identifier, storage preprocessing interaction is performed with the first server in accordance with the storage preprocessing rules corresponding to the model type in the storage specification, wherein the storage specification is used to describe the specifications and constraints when storing the model. After completing the storage preprocessing interaction, the first server stores the model file to the first storage cluster.

[0026] In some embodiments, when the size of the model file exceeds a preset size, the method further includes:

[0027] Dividing the model file into multiple sub-files; and

[0028] The first server uploads the multiple sub-files to the first storage cluster in parallel.

[0029] In a second aspect, an embodiment of the present application provides a model control device, including:

[0030] A model library display module, configured to display at least one piece of model library information obtained in response to a model acquisition condition, wherein each piece of model library information includes a business function implemented by a model in the model library;

[0031] A branch display module is configured to, in response to a selection operation on any model library information, display at least one branch information of the corresponding model library, wherein each branch information is used to describe the characteristics of a group of models in the model library when implementing a corresponding business function, and each group of models includes a training model, an intermediate model obtained by format conversion of the training model, and a device model obtained by device deployment of the intermediate model;

[0032] The model display module is used to display the model information of the corresponding group model in the model library in response to the selection operation of any branch information.

[0033] In a third aspect, an embodiment of the present application provides an electronic device, comprising: at least one processor, and a memory communicatively connected to the at least one processor, wherein:

[0034] The memory stores a computer program that can be executed by at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute any of the above-mentioned model management and control methods.

[0035] In a fourth aspect, an embodiment of the present application provides a storage medium. When the computer program in the storage medium is executed by a processor of an electronic device, the electronic device can execute any of the above-mentioned model management and control methods.

[0036] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which implements any of the above-mentioned model management and control methods when executed by a processor.

[0037] In an embodiment of the present application, in response to a model acquisition condition, at least one model library information acquired is displayed, wherein each model library information includes a business function implemented by a model in the model library, and in response to a selection operation on any model library information, at least one branch information of the corresponding model library is displayed, wherein each branch information is used to describe the characteristics of a group of models in the model library when implementing a business function, and each group of models includes a training model, an intermediate model after format conversion of the training model, and a device model after device deployment of the intermediate model, and in response to a selection operation on any branch information, the model information of the corresponding group of models in the model library is displayed. In this way, the model is stored in a manner that the training model, the intermediate model associated with the training model, and the device model associated with the intermediate model are a group of associated models. When any model is found, its associated group of models can be easily found, and model management and control are relatively easy. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0039] Figure 1 A schematic diagram of an application scenario of a model management and control method provided in an embodiment of the present application;

[0040] Figure 2 A flowchart of a model management method provided in an embodiment of the present application;

[0041] Figure 3 An interactive flow chart of a model storage provided in an embodiment of the present application;

[0042] Figure 4 A schematic diagram of a separate deployment provided in an embodiment of the present application;

[0043] Figure 5 A schematic diagram of uploading files in segments provided in an embodiment of the present application;

[0044] Figure 6 A schematic diagram of a branch provided in an embodiment of the present application;

[0045] Figure 7 A schematic diagram of a model file upload process provided in an embodiment of the present application;

[0046] Figure 8 A schematic diagram of the structure of a model control device provided in an embodiment of the present application;

[0047] Figure 9A schematic diagram of the hardware structure of an electronic device for implementing a model management and control method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0048] The embodiments of the present application provide a model management method, device, electronic device and storage medium for providing an easy-to-manage model management solution.

[0049] The preferred embodiments of the present application are described below in conjunction with the drawings in the specification. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application and are not used to limit the present application. In addition, the embodiments and features in the embodiments of the present application can be combined with each other if there is no conflict.

[0050] To facilitate understanding of this application, the technical terms involved in this application are:

[0051] Model refers to a large model with more model parameters than a preset number, such as an AI model. From training to application, large models generally need to go through three stages: training, conversion, and deployment. The large models in these three stages are training model, intermediate model, and device model. Among them, the training model is a model generated by training data, which is usually saved in the native format of the framework. For example, the model file suffix of the model trained by the PyTorch framework is .pt, and the model file suffix of the model trained by the TensorFlow framework is .pb. The intermediate model refers to a model in a universal format across frameworks, which is used to solve compatibility issues between different frameworks. Typical formats are onnx and caffe. As an intermediate bridge, it supports exporting from a training framework (such as PyTorch) and then importing it into other frameworks or deployment tools. The format conversion in the embodiment of the present application is equivalent to framework conversion. The device model is a model optimized for specific hardware.

[0052] A storage warehouse refers to a repository used to store large models and can include multiple model libraries. Generally, the models in each model library are used to implement a specific business function, and the models in different model libraries implement different business functions. Each model library may include one, two, or more branches, each containing a group of related models. For example, each branch may contain a training model, an intermediate model after format conversion of the training model, and a device model after the intermediate model has been deployed on a device. The different groups of models corresponding to different branches have different characteristics when implementing the corresponding business functions, such as different performance and applicable scenarios. For example, consider a model library used for facial recognition. Suppose it has two branches. The training model, intermediate model, and device model corresponding to one branch have high facial recognition accuracy, while the training model, intermediate model, and device model corresponding to the other branch have low facial recognition accuracy. Alternatively, the training model, intermediate model, and device model corresponding to one branch are used more for side profile scenes, while the training model, intermediate model, and device model corresponding to the other branch are used more for frontal faces.

[0053] See also Figure 1 , Figure 1 An application scenario diagram provided for an embodiment of the present application includes a client, a server, and a storage warehouse, wherein the client and the server are connected via the Internet to achieve mutual communication, and the server and the storage warehouse are connected via the Internet to achieve mutual communication. The Internet uses standard communication technologies and / or protocols. The Internet is usually the Internet, but it can also be any other network, including but not limited to a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a mobile, wired or wireless network, a private network, or any combination of a virtual private network.

[0054] The storage warehouse may include one or more storage clusters for storing model files of each model;

[0055] The client can be deployed on terminal devices such as smartphones, tablets, portable personal computers, etc. It can also be a web client, used to send model upload or download requests to the server;

[0056] The server can be deployed on a server, tablet computer, portable personal computer and other devices, and is used to upload the model file of the model to the storage warehouse in response to the client's upload request, or download the model file of the model from the storage warehouse in response to the client's download request.

[0057] After introducing the application scenarios of the embodiments of this application, the model control method proposed in this application is described below with specific embodiments. The execution subject of this method can be Figure 1 See the client in Figure 2 , Figure 2 A flowchart of a model management method provided in an embodiment of the present application includes the following steps.

[0058] In step 21 , in response to the model acquisition condition, at least one piece of model library information acquired is displayed, wherein each piece of model library information includes a business function implemented by a model in the model library.

[0059] In actual applications, each piece of model library information may also include information such as the library name, last update time, and creator of the corresponding model library.

[0060] In some embodiments, in response to the model retrieval information, at least one model library information that matches the model retrieval information can be displayed. Furthermore, the model retrieval information can be precise retrieval information such as the name of a model or the identifier of a model library, or it can be fuzzy retrieval information such as the function of the model.

[0061] In some embodiments, one or more pieces of model library information may be displayed in response to the arrival of a model push opportunity, where the model push opportunity may be, for example, the arrival of a push cycle, the user opening a model display page, or the like.

[0062] In other words, the model library information can be displayed based on the user's search, or it can be displayed to the user proactively. In this way, the model library display flexibility is better.

[0063] In step 22, in response to the selection operation of any model library information, at least one branch information of the corresponding model library is displayed, wherein each branch information is used to describe the characteristics of a group of models in the model library when realizing business functions, and each group of models includes a training model, an intermediate model after the training model is format converted, and a device model after the intermediate model is deployed on the device.

[0064] That is, when the user selects any model library information, he can see the branch information of the corresponding model library, including each branch information such as the branch name, the business function corresponding to the branch, and the business processing characteristics (that is, the characteristics of a group of models under the branch when realizing business functions).

[0065] In step 23, in response to a selection operation on any branch information, model information of the corresponding group model in the model library is displayed.

[0066] That is, when the user selects any branch information, the model information of a group of models under the corresponding branch in the model library can be displayed, such as the model description information of the training model (such as what is the training framework, what data set is used for training, model accuracy, etc.), the model description information of each intermediate model obtained by format conversion of the training model (such as what conversion tool is used for conversion, which training model is converted, what are the conversion parameters, etc.), and the model description information of the device model for deploying each intermediate model (such as what is the deployment platform, which intermediate model is deployed, what are the deployment parameters, etc.).

[0067] In step 24 , in response to a download request for any target model, the target model is downloaded, where the target model is any model in the corresponding group of models in the model library.

[0068] The target model can be a training model, an intermediate model, or a device model. The downloaded target model can be used for secondary training or conversion. That is, technicians can perform model training or format conversion based on the target model. This avoids the need to repeatedly develop similar or related models, reducing duplication of development work and accelerating the development of new features.

[0069] In this embodiment of the present application, models that implement the same business function are stored in a model library. Intermediate models associated with the same training model in the model library, as well as device models associated with the intermediate models, are stored under a single branch. A fuzzy or precise search for any model can locate the model library to which it belongs, and then find relevant information about a group of models associated with it in the model library. This makes model tracing and reproduction relatively easy, making model management and control relatively simple.

[0070] In actual applications, each model generally includes multiple model files. Some model files are accessed and updated relatively frequently, while some model files are accessed and updated relatively infrequently. In order to reduce overall storage costs while ensuring access performance, model files can be divided into first-category files and second-category files. Then, model files belonging to the first category are stored in the first storage cluster, and model files belonging to the second category are stored in the second storage cluster. Here, the storage performance of the first storage cluster is better than that of the second storage cluster, including storage performance such as throughput, number of input and output operations that can be executed per second, and latency. In addition, in order to better manage model files, the servers of the first storage cluster and the second storage cluster can also be deployed separately.

[0071] The file classification rules for classifying file types can be user-defined, such as those with certain access characteristics, files exceeding a preset size, or files with preset identifiers. For any model file, if it matches any of the file classification rules, the model file is considered to belong to the first category. If it does not match any of the file classification rules, the model file is considered to belong to the second category.

[0072] The following introduces the storage process of the target model, taking the separate storage and separate management of the model as an example.

[0073] See also Figure 3 , Figure 3 An interactive flowchart of a model storage provided in an embodiment of the present application includes the following steps.

[0074] 1. The client determines upload information in response to the model upload operation. The upload information includes multiple model files of the target model and a branch identifier. The branch identifier is used to indicate the branch to which the target model belongs.

[0075] 2. The client identifies the file type of each model file based on the file classification rules.

[0076] The file types include first-category files and second-category files.

[0077] 3. When the client determines that the file type of the model file is a first-category file, it identifies the model type corresponding to the model file.

[0078] Among them, model types include training models, intermediate models, and device models.

[0079] 4. The client performs storage preprocessing interaction with the first server based on the branch identifier and the storage preprocessing rules corresponding to the model type in the storage specification.

[0080] Storage specifications describe the specifications and constraints for model storage. Storage specifications may include storage preprocessing rules for each type of model.

[0081] For example, the storage preprocessing rules for a training model configure the following parameters: training dataset (data_set), backbone network (backbone), learning rate (learning rate), training epoch (train_epoch), training batch size (batch_size), data augmentation epoch (augment_epoch), etc. These parameters are automatically merged into the info.json file in the folder corresponding to the training model as key-value pairs. If info.json does not exist, it is created first.

[0082] For example, the storage preprocessing rules for intermediate models include: source model (source_model), model conversion tool (nnxtool), whether to perform comparison testing (is_compare), encrypted data (encrypt_data), whether to enable performance analysis (is_profile), model type (model_type), weight file (weight_file), input and output mapping of graph input name (map_input_name) and graph output name (map_output_name), dynamic shape support (dynamic_shape), quantization configuration (quantize), etc. These parameters are automatically merged into the info.json file onnx_xx in the folder corresponding to the intermediate model as key-value pairs. If info.json does not exist, it is created and the corresponding information is merged.

[0083] For example, the storage preprocessing rules for device models require the following parameters: device platform (target), simplified and removed network layers (optimize), precision quantization (quantize), input and output formats, and device model parallelism parameters. For tasks like imaging, these parameters may also include dynamic resizing (dynamic_input_shape) and whether to use half-precision (use_fp16). These parameters are automatically merged into the info.json file in the device model's corresponding folder as key-value pairs. If info.json does not exist, it will be created first.

[0084] It should be noted that the above list contains a comprehensive list of required parameters for various models. In practice, not all parameters need to be configured when uploading every model file of any particular model type. The parameters configured for each model file can be flexibly configured based on needs. The server automatically obtains the corresponding parameters. Parameters that cannot be automatically obtained can be obtained through interaction with the client (i.e., querying the client, which then fills in the relevant parameters).

[0085] 5. The client sends a model file upload request to the first server, where the upload request includes a branch identifier and a file identifier of the model file.

[0086] 6. The first server returns the information required for uploading to the client.

[0087] The information required for uploading includes the file identifier and the Uniform Resource Locator (URL) of the model file.

[0088] 7. Based on the information required for uploading, the client requests the first server to upload the model file.

[0089] 8. The first server stores the model file in the first storage cluster.

[0090] When the model file size exceeds a preset size, the client can further divide the model file into multiple sub-files. In this way, these multiple sub-files can be uploaded to the first storage cluster in parallel, thereby increasing the file upload speed and thus the model upload speed.

[0091] In addition, the first server may also generate a pointer to the model file, and associate the pointer to a corresponding folder (the folder corresponding to the model file) under a corresponding branch (the branch corresponding to the branch identifier).

[0092] 9. The first server returns a successful upload message to the client.

[0093] 10. When the client determines that the file type of the model file is a second type of file, it sends an upload request for the model file to the second server, where the upload request includes a branch identifier.

[0094] The upload request may also include a file identifier.

[0095] 11. The second server stores the model file in the second storage cluster.

[0096] In addition, the second server may also generate a pointer to the model file, and associate the pointer to a corresponding folder (the folder corresponding to the model file) under a corresponding branch (the branch corresponding to the branch identifier).

[0097] 12. The second server returns a message indicating successful upload to the client.

[0098] Subsequently, when downloading the target model, the client may send a download request for the target model to both the first server and the second server, thereby triggering the first server to download the model files of the target model belonging to the first category of files from the first storage cluster, and triggering the second server to download the model files of the target model belonging to the second category of files from the second storage cluster, thereby obtaining all the model files of the target model. Specifically, when any model file is divided into multiple sub-files and stored in the first storage cluster, the first server may download these multiple sub-files in parallel from the first storage cluster to increase the file download speed, thereby increasing the model download speed.

[0099] The following introduces the solution of the embodiment of this application by taking the AI model as an example.

[0100] The purpose of the embodiment of the present application is to provide an efficient storage and management method for AI models, which can be deployed in Figure 1 Storage warehouse shown), upload and download SDK modules (can be deployed in Figure 1), and the model display module implementation (which can be deployed in Figure 1 client, and can be deployed on other clients).

[0101] The following is an introduction to these three modules.

[0102] 1. Model storage module.

[0103] Typically, each AI model has multiple model files. Some model files are accessed frequently, while others, such as configuration files and description files, are accessed less frequently. Subsequently, frequently accessed model files will be referred to as AI files (i.e., first-category files), while less frequently accessed model files will be referred to as ordinary files (i.e., second-category files).

[0104] To better manage and control AI models, the model storage module can store and manage AI models through separate deployment. Separate deployment means storing the AI files and ordinary files of the AI model separately, and managing the codes of the AI files and ordinary files separately.

[0105] See also Figure 4 , Figure 4 This is a schematic diagram of a separate deployment provided by the embodiment of the present application. The first server and the first storage cluster for AI file storage are independently built, and the second server and the second storage cluster for general file storage are independently built. The upload and download SDK module completes operations such as model upload and model download by interacting with the first server and the second server respectively. Among them, the first server and the second server together constitute Figure 1 The first server and the second server can share the file storage location, and the first server and the second server can be deployed on different devices; the first storage cluster and the second storage cluster together constitute Figure 1 The storage warehouse in the first storage cluster has better storage performance than the second storage cluster, such as throughput, number of input and output operations that can be executed per second, latency, etc.

[0106] Separating and storing AI model files in storage clusters with different performance levels significantly improves model file read and write speeds and data security, meeting the needs of rapid AI model deployment and updates. This also maintains the lightweight and flexible nature of the standard files supporting AI models, meeting the needs of rapid AI model deployment and updates. Furthermore, independent access and storage of AI files allows for more efficient use of storage resources.

[0107] 2. Upload and download SDK modules.

[0108] In actual applications, when a user uploads any model file using the upload file function (api.upload_file()) in the upload and download SDK module, a custom pre-push hook program will be triggered to check whether the model file is an AI file based on the .gitattribute file in the storage repository. If it is an AI file, it will interact with the first server. If it is not an AI file, it will be determined to be an ordinary file and then interact with the second server. Among them, the .gitattribute file contains the identification rules for AI files (i.e., file classification rules). The identification rules can be set and changed by technical personnel according to actual needs, and will not be repeated here.

[0109] The following describes the interaction process between the upload and download SDK module and the first server.

[0110] In actual applications, an upload request is sent to the first server through the upload function (upload()) of the upload-download SDK module. The upload request may carry the object identifier (OID) of the model file, such as the sha256 value. After receiving the upload request, the first server may first determine whether the model file is already stored in the storage repository based on the model file's OID. If the model file has already been stored, the index information of the model file in the storage repository may be added to the AI model corresponding to the model file. The upload success information is returned to the upload-download SDK module without actually uploading the model file to avoid duplicate storage of the model file. If the model file has not been stored, the model file may be uploaded.

[0111] Moreover, when the file size of the model file exceeds the preset size, the upload and download SDK module can upload the model file in pieces. Specifically, the model file is automatically divided into multiple smaller sub-files, upload() calls the batch upload function (Batch upload()) to send an upload request to the first server, and the upload request carries the OID of the model file. After that, the first server will send the uniform resource locator (Uniform ResourceLocator, URL) and OID of the model file to the upload and download SDK module. The upload and download SDK module uses the URL and OID as input parameters of the basic upload function (Basic upload()), and uploads each sub-file to the first server through Basic upload(). Subsequently, the first server processes these upload tasks in parallel. When a sub-file fails to upload, you only need to re-upload the content of the sub-file. This fragmented asynchronous parallel upload method can greatly improve the upload speed and stability.

[0112] In specific implementation, the process of uploading pieces is as follows Figure 5 As shown:

[0113] 1. The upload / download SDK module sends Batch upload() to the first server. The input parameters of Batch upload() include OID, size, and operation(upload). Size indicates the file size of the model file to be uploaded.

[0114] 2. The first server returns the URL and OID of the model file to the upload and download SDK module;

[0115] 3. The upload / download SDK module sends Basic upload() to the first server. The input parameters of Basic upload() include the URL and OID of the model file just returned, and transfers each sub-file of the model file.

[0116] 4. The first server writes each sub-file to the first storage cluster;

[0117] 5. The first storage cluster sends a write completion message to the first server;

[0118] 6. The first server returns a message indicating that the model file has been successfully uploaded to the upload and download SDK module.

[0119] In this way, the model files of the AI model are uploaded in parallel, and the file upload speed is faster, and the model upload speed is also faster.

[0120] In practical applications, AI model storage protocols can be customized in advance. Subsequently, when users upload AI models, the upload and download SDK module automatically generates supporting files for the AI model according to the storage protocol and stores them in the storage warehouse. This improves the efficiency and accuracy of model file management and facilitates the traceability and reproduction of AI models.

[0121] The following is an introduction to the storage specifications of AI models.

[0122] The storage protocol for AI models refers to the constraints and specifications related to AI model storage. Generally, AI models handling the same business are managed within the same project (corresponding to a model library), and project-related information (i.e., model library information) such as the project name, project identifier, project description, members, modification time, and creator is stored in the storage repository. Furthermore, AI models within a model library are managed through branches based on different performance characteristics (e.g., high precision, low precision), applicable scenarios (e.g., more frontal face images, more profile images), and applicable product projects. Specifically, a set of business-specific AI models (i.e., a model group) is stored within the same branch, including the training model, the intermediate model after format conversion of the training model, and the device model after the intermediate model is deployed on devices. Furthermore, each AI model corresponds to a folder containing the AI model's supporting files (which can be automatically generated by the SDK upload / download module based on the model type and configuration rules when uploading the AI model file). Comprehensive storage protocols are crucial for the traceability and reproduction of AI models, as well as for secondary optimization of AI models, and can significantly improve the efficiency of AI model usage.

[0123] In some embodiments, the branch naming rule in the storage specification is: {model name}_{business function}_{performance scenario}_{custom}. Figure 6 , Figure 6 A schematic diagram of a branch provided in an embodiment of the present application, wherein "pvndetect_perimeter_low" is a branch information item, "pvndetect" is the model name (or model group name), "perimeter" is the business function, and "low" is performance, indicating that the AI model group under the branch has low performance in perimeter recognition. The branch includes a training model (trainmodel), four intermediate models (with different frameworks) obtained by formatting trainmodel: caffmodel_1, caffmodel_2, onnx_1, and onnx_2, and a device model (ax650_010_fp16) obtained by deploying one of the intermediate models. Each AI model corresponds to a folder. The splicing rule for the folder corresponding to "caffmodel" is: "caffmodel_{user-defined}", the splicing rule for the folder corresponding to "onnx" is: "onnx_{user-defined}", and the splicing rule for the folder corresponding to the device model is: "{device platform}_{sdk}_{quantization accuracy}".

[0124] The following is an introduction to the folders under the branch.

[0125] The trainmodel folder contains model file 1, model file 2, configuration files info.json, xxx.json, and other related files. Info.json is used to describe the model information of trainmodel, including the training dataset, training task identifier, etc. The model information saved in info.json can be customized by the user. xxx.json is a related configuration file that is valid for all AI models under this branch.

[0126] The caffmodel_1 folder contains model files 3, 4, and 5, as well as the configuration file info.json. The info.json file describes the model information of caffmodel_1, such as which version of the training model in which directory was converted, and which configuration file is used.

[0127] The caffmodel_2 folder contains model files 6 and 7, and the configuration file info.json. The info.json file describes the model information of caffmodel_2, such as which version of the training model in which directory was converted, and which configuration file is used.

[0128] The onnx_1 folder contains model file 8 and configuration file info.json. Info.json is used to describe the model information of onnx_1, such as which version of the training model in which directory was converted;

[0129] The onnx_2 folder contains model file 9 and configuration file info.json. Info.json is used to describe the onnx_2 model information, such as which version of the training model in which directory was converted;

[0130] The ax650_010_fp16 folder contains model files 10, 1.json, and a configuration file info.json. 1.json is the conversion configuration parameter file for converting to a device model. Info.json describes model information about the ax650_010_fp16, such as the intermediate model version in the directory from which it was converted, and the version number of the conversion tool client.

[0131] Next, the process of uploading model files using the upload and download SDK module under the above storage protocol is introduced.

[0132] When uploading a model file using the upload / download SDK module, you are required to pass in the corresponding parameters based on the model type (training model, intermediate model, or device model). The upload / download SDK module automatically generates the corresponding configuration file and stores it in the corresponding folder. For example, the configuration file info.json for the training model is automatically generated in the folder corresponding to the training model, and the configuration file info.json for the intermediate model is automatically generated in the folder corresponding to the intermediate model. The specific generation rules are as follows:

[0133] 1) When users use the upload / download SDK module to upload a folder to the storage warehouse, for each model file in the folder, the model category of the AI model to which the model file belongs can be identified based on the suffix of the model file.

[0134] In actual applications, users can also forcibly specify the model type corresponding to a model file through the model_type parameter. If the user does not forcibly specify the model type corresponding to a model file, the model type corresponding to the model file can be identified according to the following rules:

[0135] Model files with suffixes such as .pt, .pth, .h5, and .ckpt usually belong to unoptimized models derived directly from the training process. They contain complete model architecture and weight information and are suitable for further training, evaluation, or fine-tuning. Therefore, model files with these suffixes can be identified as training models.

[0136] Model files with suffixes such as .onnx, .caffe, and .pb are converted from trained models and are typically used for cross-framework model migration or as a starting point for model optimization. They may contain additional metadata, such as input and output specifications and preprocessing parameters, to facilitate secondary development and deployment of the model. Therefore, model files with these suffixes are identified as intermediate models if model_type is not specified.

[0137] Model files with suffixes such as .nnx, .tflite, and .bin belong to models that have been optimized and converted to a model format specifically for edge devices or specific hardware platforms. They may have undergone optimization steps such as quantization, pruning, and fusion to adapt to limited computing resources and real-time requirements. Therefore, model files with these suffixes can be identified as device models.

[0138] 2) Generate the configuration file of the AI model (storing the preprocessing interaction results) according to the configuration file generation rules corresponding to the model type (i.e., storing the preprocessing rules).

[0139] If the model type is a training model, the configuration file generation rules include configuring the following parameters: training dataset (data_set), backbone network (backbone), learning rate (learning rate), training rounds (train_epoch), training batch size (batch_size), data augmentation rounds (augment_epoch), etc. These parameters are automatically merged into the info.json file in the folder corresponding to the training model as key-value pairs. If info.json does not exist, it will be created first.

[0140] If the model type is an intermediate model, such as an onnx model, the configuration file generation rules include requirements for the source model (source_model), the model conversion tool (nnxtool), whether to perform comparison testing (is_compare), encrypted data (encrypt_data), whether to enable performance analysis (is_profile), the model type (model_type), the weight file (weight_file), the input and output mapping of the graph input name (map_input_name) and graph output name (map_output_name), dynamic shape support (dynamic_shape), and quantization configuration (quantize). These parameters are automatically merged into the info.json file (onnx_xx) in the folder corresponding to the intermediate model as key-value pairs. If info.json does not exist, it is created and the corresponding information is merged. If the intermediate model is a Caffe model, the Caffe model description file (.prototxt) is automatically generated in the folder corresponding to the intermediate model (e.g., caffe_xx) based on the relevant configuration of the source trained model.

[0141] If the model type is a device model, the configuration file generation rules require the following parameters: device platform (target), simplified and removed network layers (optimize), precision quantization (quantize), input and output formats, and device model parallelism parameters. For tasks like imaging, these parameters may also include dynamic resizing (dynamic_input_shape) and whether to use half-precision (use_fp16). These parameters are automatically merged into the info.json file in the device model's corresponding folder as key-value pairs. If the info.json file does not exist, it is created first and then the corresponding information is merged.

[0142] It should be noted that the above lists the parameters that need to be configured for various AI models in a relatively comprehensive manner. In actual applications, for any type of model, it is not necessary to configure these parameters when uploading every model file of this type of model. The parameters configured for each model file can be flexibly configured according to needs.

[0143] 3) Save the model file in the folder corresponding to the model type. Generally, except for the configuration file info.json, the file names in different folders corresponding to the same model type are unique. Therefore, you can first determine whether there are files with the same name in the folders corresponding to the model type based on the name of the model file. If so, replace the files with the model file in the corresponding folder. If not, it means that this is a new AI model, and the model folder can be automatically created. For example, if the intermediate model is recognized as being in the onnx format, a folder named onnx_XX will be created, and then the model file will be saved in this folder.

[0144] 4) Store model name (model_name), business function (function), scene information (scene_info), optional input (optional_input), optional output (optional_output) and other information in the storage warehouse to supplement the model's metadata storage information for subsequent model retrieval and use.

[0145] In actual applications, the download request sent by the upload / download SDK module to the first server can include the model identifier of the AI model. Based on the model identifier, the first server can download the AI model's AI file from the first storage cluster. Furthermore, if any AI file is divided into multiple sub-files, the first server can download these sub-files from the first storage cluster in parallel. This parallel downloading of the AI model's model files also results in faster download speeds.

[0146] Next, the interaction process between the upload and download SDK module and the second server is introduced.

[0147] In actual applications, the upload request sent by the upload and download SDK module to the second server may carry the OID of the model file, such as the sha256 value. The second server creates a pointer to the model file based on the OID and stores the model file in the second storage cluster.

[0148] The download request sent by the upload-download SDK module to the second server can carry the model identifier of the AI model. Based on the model identifier, the second server can download the ordinary file of the AI model from the first storage cluster.

[0149] In addition, it should be noted that in actual applications, multiple model files of an AI model are generally downloaded. At this time, the upload and download SDK module will send download requests to both the first server and the second server, thereby triggering the first server to download the AI file of the AI model from the first storage cluster, and triggering the second server to download the ordinary file of the AI model from the second storage cluster.

[0150] As can be seen from the above introduction, the upload and download SDK module provides users with a unified set of AI model upload and download capabilities. This standardized packaging of capabilities also makes it easy for users to directly integrate the upload and download SDK module into their AI development programs, greatly reducing the complexity of accessing and uploading AI models, simplifying the model file management process, and providing a unified programming interface, making AI model upload and download operations more convenient, thereby lowering the threshold for developers. In addition, the automatic generation of corresponding configuration files based on model type also facilitates AI model traceability and use.

[0151] The following describes the model file upload process in conjunction with the upload and download SDK module and the model storage module.

[0152] See also Figure 7 , Figure 7 A schematic diagram of the uploading process of a model file provided in an embodiment of the present application includes the following steps.

[0153] In step 71, the user selects a branch and uploads a folder through the upload / download SDK module.

[0154] The model files in the folder may belong to the same AI model or multiple AI models.

[0155] In step 72, the upload / download SDK module traverses the model files in the folder and identifies the file type of each model file traversed.

[0156] For example, the file type is identified according to the preset file classification rules. The file classification rules can be customized by the user. When the model file matches the file classification rules, the model file can be determined to be an AI file. Otherwise, the model file is determined to be an ordinary file.

[0157] In step 73, when the model file is a common file, the upload / download SDK module submits an upload request for the model file to the second server.

[0158] The upload request may include the OID of the model file.

[0159] In step 74 , the second server generates a pointer file of the model file, uploads the model file to the second storage cluster, and proceeds to step 716 .

[0160] In step 75, when the model file is an AI file, the upload and download SDK module performs model category identification based on the model file.

[0161] In step 76 , when the model category corresponding to the model file is an intermediate model, the parameters required for the intermediate model are interactively configured.

[0162] Among them, the parameters required for the intermediate model include the source model (source_model), model conversion tool (nnxtool), whether to perform comparison testing (is_compare), encrypted data (encrypt_data), whether to enable performance analysis (is_profile), model type (model_type), weight file (weight_file), input and output mapping of graph input name (map_input_name) and graph output name (map_output_name), dynamic shape support (dynamic_shape), quantization configuration (quantize), etc.

[0163] In step 77 , the configured parameters are written into the info.json file in the folder corresponding to the intermediate model, and the process proceeds to step 712 .

[0164] For example, write the configured parameters in the form of key-value pairs into the info.json file in the folder corresponding to the intermediate model.

[0165] In step 78, when the model category corresponding to the model file is a training model, the parameters required for the training model are interactively configured.

[0166] Among them, the parameters required for training the model include training data set (data_set), backbone network (backbone), learning rate (learning rate), training round (train_epoch), training batch size (batch_size), data enhancement round (augment_epoch), etc.

[0167] In step 79 , the configured parameters are written to the info.json file in the folder corresponding to the training model, and the process goes to step 712 .

[0168] For example, write the configured parameters in the form of key-value pairs into the info.json file in the folder corresponding to the training model.

[0169] In step 710 , when the model category corresponding to the model file is a device model, parameters required for the device model are interactively configured.

[0170] Among them, the parameters required by the device model include the device platform (target), simplified and removed network layers (optimize), precision quantization (quantize), input and output formats, and device model parallel parameters.

[0171] In step 711 , the configured parameters are written into the info.json file in the folder corresponding to the device model, and the process proceeds to step 712 .

[0172] For example, write the configured parameters in the form of key-value pairs into the info.json file in the folder corresponding to the device model.

[0173] In step 712, the upload / download SDK module submits an upload request for the model file to the first server.

[0174] The upload request includes the OID of the model file.

[0175] In step 713, the first server generates a pointer file of the model file and returns the information required for uploading to the upload and download SDK module.

[0176] Among them, upload the required information such as the URL and OID of the model file.

[0177] In step 714 , the upload / download SDK module starts the source file upload task of the model file.

[0178] In step 715 , the first server uploads the model file to the first storage cluster.

[0179] In step 716, the model storage module saves the source description information of the model file and generates a matching retrieval index.

[0180] Next, the model display module is introduced.

[0181] 3. Model display module.

[0182] In order to solve the problem of AI model retrieval and traceability, facilitate model secondary optimization and use, and improve the efficiency and utilization of AI model management, the model display module can display rich model metadata information, including: model library name, model library address, model version number, model creation time, model function description, model creator, model training description information (including model training data set, model training image size, model backbone network information, etc.), intermediate model conversion information (including model conversion source, model conversion configuration, etc.), device model information (including model applicable platform, model quantization accuracy, quantization parameters, etc.), model algorithm category, model function, applicable scenarios, and other information.

[0183] The model display module can also provide a visual interface to display the AI models stored in the system. Users can see the AI models stored in the storage warehouse and the supporting files of the AI models. When users want to find a certain type of AI model they need, it can also provide multi-dimensional fuzzy retrieval functions, such as fuzzy search for AI models according to model description, functional information, model name, applicable scenarios and other information.

[0184] The following introduces several display situations of the model display module.

[0185] 1. Actively recommend AI models.

[0186] 1.1. The background of the model display module can asynchronously and periodically request the second server (the following information is usually stored and managed by the second server) to update and maintain the model database information in the background, such as updating the model modification time (modify_time), model name (model_name) addition and deletion, model description information (model_description) modification, business function (function) and other information.

[0187] 1.2. The model display module can use the AI model creation time sorting by default and display the background model database information in pages, where each model database information such as model library name, model library description information, model library last update time, model library address, etc.

[0188] 2. Accurately query AI models.

[0189] If the user already knows the model name of the AI model or the model library identifier, the corresponding model library can be accurately queried according to the model name or model library identifier passed in by the user.

[0190] 3. Fuzzy query AI model.

[0191] 3.1. If the user only knows the functional description or applicable scenarios of the AI model, a fuzzy search can be performed. For example, a user wants to find an AI model for license plate detection for secondary optimization and use. When the user enters "license plate detection" on the model display module interface, the background fuzzy matches the model library description information, applicable functions, scenarios, model name, and other information. If there is a relevant model library, the relevant model library information is filtered out for the user and displayed on the interface. Each model library information can be represented as a model library tab.

[0192] 3.2 The user clicks on any model library tab to expand the branch of the corresponding model library. The user can select a branch on the page to display the file list under the model library. The file list information is generated by the model upload and download SDK module according to the storage specification. The training model, intermediate model, and device model are all stored in their corresponding folders. The user can enter the folder to view the configuration file info.json corresponding to each AI model to determine the model source and perform model backtracking.

[0193] 3.3. If a user finds an AI model, such as an intermediate model for license plate detection, they can view the relevant configuration during model training and the corresponding parameters when converting it to the intermediate model, thus achieving model traceability. They can also use the download function (hf_hub_download()) supported by the model upload and download SDK module to download the intermediate model to the working environment for subsequent secondary training and conversion, such as further conversion to a device model for their own use.

[0194] The model display module provides rich and diverse model metadata information, coupled with convenient and efficient search and display functions, greatly facilitating users' search and use of AI models. Recording information such as the training model's dataset, backbone network, and enhancement parameters, as well as the conversion parameters and quantization accuracy of intermediate model device models, facilitates model traceability and reproduction, and greatly facilitates secondary model tuning, thereby improving AI model utilization and reducing duplicate storage.

[0195] The embodiments of this application propose an efficient storage and management method suitable for AI models, which has obvious advantages in uploading, storing, tracing, and displaying AI models, and provides a complete and comprehensive solution for the storage and management of AI models.

[0196] Based on the same technical concept, an embodiment of the present application also provides a model control device. The principle of solving the problem by the model control device is similar to that of the above-mentioned model control method. Therefore, the implementation of the model control device can refer to the implementation of the model control method, and the repeated parts will not be repeated.

[0197] Figure 8 A schematic structural diagram of a model control device provided in an embodiment of the present application includes:

[0198] The model library display module 801 is used to display at least one piece of model library information obtained in response to the model acquisition condition, wherein each piece of model library information includes a business function implemented by a model in the model library;

[0199] A branch display module 802 is configured to, in response to a selection operation on any model library information, display at least one branch information of the corresponding model library, wherein each branch information is used to describe the characteristics of a group of models in the model library when implementing a corresponding business function, and each group of models includes a training model, an intermediate model obtained by format conversion of the training model, and a device model obtained by device deployment of the intermediate model;

[0200] The model display module 803 is configured to display the model information of the corresponding group model in the model library in response to a selection operation on any branch information.

[0201] In some embodiments, the model library display module 801 is specifically used to:

[0202] In response to the model retrieval information, display at least one model library information that matches the model retrieval information; or,

[0203] In response to the arrival of the model push opportunity, the at least one piece of model library information is displayed.

[0204] In some embodiments, a model download module 804 is further included for:

[0205] After displaying the model information of the corresponding group of models in the model library, in response to a download request for any target model, the target model is downloaded, where the target model is any model in the corresponding group of models in the model library.

[0206] In some embodiments, the target model includes a plurality of model files, each of which belongs to the first type of file or the second type of file; and a model download module 804, specifically configured to:

[0207] Sending a download request for the target model to a first server, triggering the first server to download a model file of the target model belonging to the first category of files from a first storage cluster;

[0208] A download request for the target model is sent to a second server, triggering the second server to download a model file of the target model belonging to the second category of files from a second storage cluster, where the storage performance of the second storage cluster is lower than that of the first storage cluster.

[0209] In some embodiments, when the size of any model file exceeds a preset size, the model file is divided into multiple sub-files and stored in the first storage cluster, and

[0210] The first server downloads the multiple sub-files in parallel from the first storage cluster.

[0211] In some embodiments, a model storage module 805 is further included, configured to store the target model according to the following steps:

[0212] In response to the model upload operation, determining upload information, the upload information including a plurality of model files of the target model and a branch identifier, the branch identifier being used to indicate the branch to which the target model belongs;

[0213] For any model file, if the model file belongs to the first category of files, sending an upload request for the model file to the first server, wherein the upload request includes the branch identifier, triggering the first server to store the model file in the first storage cluster;

[0214] If the model file belongs to the second type of file, an upload request for the model file is sent to the second server, where the upload request includes the branch identifier, triggering the second server to store the model file in the second storage cluster.

[0215] In some embodiments, the model storage module 805 is further configured to:

[0216] If the model file belongs to the first category of files, identifying the model type corresponding to the model file;

[0217] According to the branch identifier, storage preprocessing interaction is performed with the first server in accordance with the storage preprocessing rules corresponding to the model type in the storage specification, wherein the storage specification is used to describe the specifications and constraints when storing the model. After completing the storage preprocessing interaction, the first server stores the model file to the first storage cluster.

[0218] In some embodiments, when the size of the model file exceeds a preset size, the method further includes:

[0219] Dividing the model file into multiple sub-files; and

[0220] The first server uploads the multiple sub-files to the first storage cluster in parallel.

[0221] The division of modules in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, the functional modules in the embodiments of the present application may be integrated into one processor, or may exist physically separately, or two or more modules may be integrated into one module. The coupling between the modules can be achieved through some interfaces, which are usually electrical communication interfaces, but it is not ruled out that they may be mechanical interfaces or other forms of interfaces. Therefore, the modules described as separate components may or may not be physically separated, and may be located in one place or distributed to different locations of the same or different devices. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software functional modules.

[0222] After introducing the model control method and apparatus according to an exemplary embodiment of the present application, an electronic device according to another exemplary embodiment of the present application is introduced next.

[0223] Refer to the following Figure 9 The electronic device 130 implemented according to this embodiment of the present application is described. Figure 9 The electronic device 130 shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0224] like Figure 9 As shown, the electronic device 130 is a general electronic device. Components of the electronic device 130 may include, but are not limited to, the at least one processor 131, the at least one memory 132, and a bus 133 connecting different system components (including the memory 132 and the processor 131).

[0225] Bus 133 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a processor or local bus using any of a variety of bus architectures.

[0226] The memory 132 may include a readable medium in the form of a volatile memory, such as a random access memory (RAM) 1321 and / or a cache memory 1322 , and may further include a read-only memory (ROM) 1323 .

[0227] The memory 132 may also include a program / utility 1325 having a set (at least one) of program modules 1324, such program modules 1324 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0228] The electronic device 130 may also communicate with one or more external devices 134 (e.g., a keyboard, pointing device, etc.), one or more devices that enable a user to interact with the electronic device 130, and / or any device that enables the electronic device 130 to communicate with one or more other electronic devices (e.g., a router, a modem, etc.). Such communication may occur via an input / output (I / O) interface 135. Furthermore, the electronic device 130 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network such as the Internet) via a network adapter 136. As shown, the network adapter 136 communicates with other modules of the electronic device 130 via a bus 133. It should be understood that, although not shown, other hardware and / or software modules may be used in conjunction with the electronic device 130, including but not limited to microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0229] In an exemplary embodiment, the electronic device of the present application may include at least one processor and a memory communicatively connected to the at least one processor, wherein the memory stores a computer program that can be executed by the at least one processor, and when the computer program is executed by the at least one processor, the at least one processor can execute the steps of any model management method provided in the embodiments of the present application.

[0230] In an exemplary embodiment, a storage medium is also provided. When a computer program in the storage medium is executed by a processor of an electronic device, the electronic device can perform any of the above-mentioned model management and control methods. Optionally, the storage medium can be a non-transitory computer-readable storage medium, for example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0231] In an exemplary embodiment, a computer program product is further provided. When the computer program product is executed by an electronic device, the electronic device can implement any exemplary method provided in this application.

[0232] It should be noted that although several modules or submodules of the device are mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, depending on the embodiment of the application, the features and functions of two or more modules described above can be embodied in one module. Conversely, the features and functions of one module described above can be further divided and embodied by multiple modules.

[0233] Furthermore, although the operations of the method of the present application are described in a particular order in the accompanying drawings, this does not require or imply that the operations must be performed in this particular order, or that all illustrated operations must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0234] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0235] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present application.

[0236] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application also includes these modifications and variations.

Claims

1. A model management and control method, characterized in that: include: In response to the model acquisition condition, display at least one piece of model library information acquired, wherein each piece of model library information includes a business function implemented by a model in the model library; In response to a selection operation on any model library information, at least one branch information of the corresponding model library is displayed, wherein each branch information is used to describe the characteristics of a group of models in the model library when implementing a corresponding business function, and each group of models includes a training model, an intermediate model after format conversion of the training model, and a device model after the intermediate model is deployed on a device; In response to a selection operation on any branch information, model information of a corresponding group of models in the model library is displayed.

2. The method according to claim 1, wherein In response to the model acquisition condition, at least one piece of model library information obtained is displayed, including: In response to the model retrieval information, display at least one model library information that matches the model retrieval information; or, In response to the arrival of the model push opportunity, the at least one piece of model library information is displayed.

3. The method according to claim 1 or 2, wherein: After displaying the model information of the corresponding group of models in the model library, the method further includes: In response to a download request for any target model, the target model is downloaded, where the target model is any model in a corresponding group of models in the model library.

4. The method according to claim 3, wherein The target model includes a plurality of model files, each of which belongs to the first category of files or the second category of files; as well as Download the target model, including: Sending a download request for the target model to a first server, triggering the first server to download a model file of the target model belonging to the first category of files from a first storage cluster; A download request for the target model is sent to a second server, triggering the second server to download a model file of the target model belonging to the second category of files from a second storage cluster, where the storage performance of the second storage cluster is lower than that of the first storage cluster.

5. The method according to claim 4, wherein When the size of any model file exceeds a preset size, the model file is divided into multiple sub-files and stored in the first storage cluster, and The first server downloads the multiple sub-files in parallel from the first storage cluster.

6. The method according to claim 4, wherein The target model is stored according to the following steps: In response to the model upload operation, determining upload information, the upload information including a plurality of model files of the target model and a branch identifier, the branch identifier being used to indicate the branch to which the target model belongs; For any model file, if the model file belongs to the first category of files, sending an upload request for the model file to the first server, wherein the upload request includes the branch identifier, triggering the first server to store the model file in the first storage cluster; If the model file belongs to the second type of file, an upload request for the model file is sent to the second server, where the upload request includes the branch identifier, triggering the second server to store the model file in the second storage cluster.

7. The method according to claim 6, wherein If the model file belongs to the first category of files, the method further includes: Identify the model type corresponding to the model file; According to the branch identifier, storage preprocessing interaction is performed with the first server in accordance with the storage preprocessing rules corresponding to the model type in the storage specification, wherein the storage specification is used to describe the specifications and constraints when storing the model. After completing the storage preprocessing interaction, the first server stores the model file to the first storage cluster.

8. The method according to claim 6, wherein When the size of the model file exceeds a preset size, the following steps are also included: Dividing the model file into multiple sub-files; and The first server uploads the multiple sub-files to the first storage cluster in parallel.

9. A model control device, characterized in that: include: A model library display module, configured to display at least one piece of model library information obtained in response to a model acquisition condition, wherein each piece of model library information includes a business function implemented by a model in the model library; A branch display module is configured to, in response to a selection operation on any model library information, display at least one branch information of the corresponding model library, wherein each branch information is used to describe the characteristics of a group of models in the model library when implementing a corresponding business function, and each group of models includes a training model, an intermediate model obtained by format conversion of the training model, and a device model obtained by device deployment of the intermediate model; The model display module is used to display the model information of the corresponding group model in the model library in response to the selection operation of any branch information.

10. An electronic device, characterized in that: include: at least one processor, and a memory communicatively coupled to the at least one processor, wherein: The memory stores a computer program executable by the at least one processor. The computer program is executed by the at least one processor so as to enable the at least one processor to perform the method according to any one of claims 1 to 8.

11. A storage medium, characterized in that: When the computer program in the storage medium is executed by a processor of an electronic device, the electronic device can perform the method according to any one of claims 1 to 8.

12. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 8 when executed by a processor.

Images