Model conversion method and related apparatus
By using CI system parsing and container image technology, the standardized model was automatically adapted to different chip platforms, solving the problems of high difficulty and low efficiency in model deployment, and improving the efficiency and consistency of model deployment.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING REALAI TECH CO LTD
- Filing Date
- 2023-10-25
- Publication Date
- 2026-07-24
AI Technical Summary
The different chip deployment logics of different manufacturers make it difficult and inefficient to deploy standardized models, and also increase the difficulty of maintenance.
By parsing standardized models through the CI system, building container images, and executing target workflows, the system achieves automated adaptation between standardized models and different chips in non-standard systems, including model format conversion, quantization, and compression.
It reduces the difficulty of model deployment, improves the efficiency and consistency of model deployment, and ensures consistency and repeatability across different chip platforms.
Smart Images
Figure CN117453237B_ABST
Abstract
Description
Technical Field
[0011] ,
[0010] ,
[0001] The embodiments of the present application relate to the field of data processing, and more specifically to a model conversion method and related devices. Background Art
[0002] Artificial intelligence has been widely applied in multiple complex scenarios, which depends on the increasingly mature domestic chip solutions.
[0003] In the wave of domestic chip development, although more and more domestic chips have emerged and been put into use, the application tools supporting these chips lack consistency and are difficult to handle the differences between various chips. However, there are differences in the equipment and chip deployment logics of different manufacturers, which makes it necessary to adapt according to the different chips used in the system backend during the standardized model deployment process, resulting in high deployment difficulty and low deployment efficiency. In addition, due to the differences in the maintenance methods of different chips, an increase in the types of backend chips will further exacerbate the maintenance difficulty.
[0004] In summary, there is an urgent need to design a new technical solution to solve the adaptation problem between the standardized model and different chips in the non-standard system, reduce the model deployment difficulty, and improve the model deployment efficiency. Summary of the Invention
[0005] The embodiments of the present application provide a model conversion method and related devices, which can achieve automatic adaptation processing between the standardized model and different chips in the non-standard system, reduce the model deployment difficulty, and improve the model deployment efficiency.
[0006] In a first aspect, the embodiments of the present application provide a model conversion method, which includes:
[0007] Parse the standardized model to be processed through a Continuous Integration (CI) system to obtain the standardized configuration information of the standardized model;
[0008] Load the standardized model into a container image that matches the standardized configuration information; wherein, the container image is used to provide a conversion environment for the standardized model;
[0009] Construct a target workflow for converting the standardized model according to the standardized configuration information; the target workflow at least includes the following processes: model format conversion, model quantization, model compression; the process parameters in the target workflow are determined by the chip configuration carried in the non-standard platform; <00XXXXX1>
[0010] Execute the target workflow in the container image to convert the standardized model into a deployment model for release on the non-standard platform.
[0011] Secondly, embodiments of this application provide a model conversion apparatus having the function of implementing the model conversion method corresponding to the first aspect described above. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described function; the modules can be software and / or hardware. In one embodiment, the apparatus includes:
[0012] The parsing module is configured to parse the standardized model to be processed through the CI system in order to obtain the standardized configuration information of the standardized model;
[0013] The loading module is configured to load the standardized model into a container image that matches the standardized configuration information; the container image is used to provide a transformation environment for the standardized model.
[0014] The building module is configured to construct a target workflow for converting standardized models based on standardized configuration information. The target workflow includes at least the following processes: model format conversion, model quantization, and model compression. The process parameters in the target workflow are determined by the chip configuration on the non-standard platform.
[0015] The execution module is configured to execute the target workflow within the container image to convert the standardized model into a deployment model for deployment on non-standard platforms.
[0016] Thirdly, embodiments of this application provide a computing device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the model conversion method described in the first aspect.
[0017] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the model conversion method described in the first aspect.
[0018] Fifthly, embodiments of this application provide a chip that includes a processor coupled to a transceiver of a terminal device, for executing the technical solution provided in the first aspect of embodiments of this application.
[0019] In a sixth aspect, embodiments of this application provide a chip system including a processor for supporting a terminal device in implementing the functions involved in the first aspect above, such as generating or processing information involved in the method provided in the first aspect above.
[0020] In one possible design, the aforementioned chip system also includes a memory for storing program instructions and data necessary for the terminal. The chip system can be composed of chips or may include chips and other discrete components.
[0021] In a seventh aspect, embodiments of this application provide a computer program product containing instructions that, when run on a computer, cause the computer to perform the method provided in the first aspect described above.
[0022] Compared to related technologies, in this embodiment, a CI system is used to parse the standardized model to be processed to obtain its standardized configuration information. Parsing the standardized model yields standardized configuration information, including the model's architecture, hierarchical structure, and input / output formats. This information provides a data foundation for subsequent model conversion and deployment processes. The standardized model is then loaded into a container image matching the standardized configuration information. This container image provides the conversion environment for the standardized model. The container image isolates the standardized model's runtime environment, ensuring consistency and making the standardized model conversion process repeatable and portable across different non-standard platforms. This ensures that the standardized model can be converted and deployed in the same way on different non-standard platforms. Next, based on the standardized configuration information, a target workflow for converting the standardized model is constructed. This target workflow is then executed within the container image to convert the standardized model into a deployment model for deployment on non-standard platforms. The target workflow includes at least the following processes: model format conversion, model quantization, and model compression. The target workflow in this application can be automatically customized according to the deployment requirements of different standardized models, including data conversion, model compression, optimization, and related parameters, thereby ensuring that standardized models can be efficiently ported to non-standard platforms. It is understood that the process parameters in the target workflow are determined by the chip configuration on the non-standard platform. Thus, by dynamically adjusting the process parameters in the target workflow based on the chip configuration on the non-standard platform, the model can be matched to the performance and characteristics of the non-standard platform to the greatest extent possible. This flexibility ensures that the model achieves optimal performance and results on the non-standard platform.
[0023] Compared to related technologies, this application provides a novel model conversion method. By constructing a target workflow for converting standardized models and executing the target workflow in a container image, it achieves automated adaptation between standardized models and different chips in non-standard systems, reducing the difficulty of model deployment and improving model deployment efficiency. Attached Figure Description
[0024] The objectives, features, and advantages of the embodiments of this application will become readily understood by referring to the accompanying drawings and the detailed description of the embodiments. Wherein:
[0025] Figure 1 This is a schematic diagram of a model conversion system in an embodiment of this application;
[0026] Figure 2 This is a flowchart illustrating a model conversion method in an embodiment of this application.
[0027] Figure 3 This is a flowchart illustrating one model parsing method in an embodiment of this application;
[0028] Figure 4 This is a flowchart illustrating a container image building method in an embodiment of this application.
[0029] Figure 5 This is a schematic diagram of a model conversion device in one embodiment of this application;
[0030] Figure 6 This is a schematic diagram of the structure of a computing device in an embodiment of this application;
[0031] Figure 7 This is a schematic diagram of a server structure in one embodiment of this application.
[0032] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation
[0033] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those explicitly listed, but may include other steps or modules not explicitly listed or inherent to these processes, methods, products, or devices. The division of modules in the embodiments of this application is merely a logical division; in actual applications, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be omitted or not performed. Additionally, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interface, indirect coupling between modules, or electrical or other similar forms of communication connection, none of which are limited in the embodiments of this application. Furthermore, the modules or sub-modules described as separate components may or may not be physically separated, may or may not be physical modules, or may be distributed among multiple circuit modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the embodiments of this application.
[0034] This application provides a model conversion method applicable to standardized model deployment scenarios, involving at least one service device, which includes at least one model conversion device. For example, a service device includes a model conversion device for executing steps at different stages of model conversion. For instance, the model conversion device is used to construct a target workflow for converting standardized models and execute the target workflow in a container image to achieve automated adaptation processing between standardized models and different chips in non-standard systems, reducing the difficulty of model deployment and improving model deployment efficiency. The model conversion device can be an application that constructs a target workflow for converting standardized models and executes the target workflow in a container image to achieve automated adaptation processing between standardized models and different chips in non-standard systems, or a server that has installed the application that constructs a target workflow for converting standardized models and executes the target workflow in a container image to achieve automated adaptation processing between standardized models and different chips in non-standard systems.
[0035] The solutions provided in this application involve concepts such as cloud-native and containers, as detailed below:
[0036] Cloud-native refers to a cloud technology product system built upon distributed cloud deployment and unified operation and management, using technologies such as containers, microservices, and DevOps. Cloud-native applications, designed specifically for the cloud, allow developers to fully leverage the elasticity and distributed advantages of the cloud platform, enabling rapid deployment, on-demand scaling, and uninterrupted delivery, without needing to consider the underlying technical implementation.
[0037] Containers are an open-source containerization platform that helps developers package applications and their dependencies into portable containers. A container is a lightweight, isolated, and portable runtime environment that contains all the components an application needs (such as code, runtime, libraries, and system tools). Containerization enables applications to run consistently in any environment, whether for development, testing, deployment to production, or porting to other cloud platforms. Docker provides the concept of a container image, an executable software package containing everything needed to run a container, including code, runtime, system tools, libraries, and configuration information. Container images are portable and can be deployed and shared across different hosts. By using Docker, rapid, consistent, and reliable application delivery and deployment can be achieved, reducing friction between developers and operations personnel and improving system portability, scalability, and resource utilization.
[0038] In the standardized model deployment scenario in the related art, a variety of different chips are usually installed in the platform to be deployed, but the application tools supporting the multiple chips lack consistency and it is difficult to handle the differences between various chips, resulting in the need for adaptation according to the different chips used in the system backend during the standardized model deployment process, with high deployment difficulty and low deployment efficiency. In addition, since the maintenance methods of different chips are different, an increase in the types of backend chips will further lead to an increase in maintenance difficulty.
[0039] Compared with the manual platform deployment solutions for different chips in the related art, the embodiments of the present application provide a model conversion solution, which can achieve automated adaptation processing between a standardized model and different chips in a non-standard system by constructing a target workflow for converting the standardized model and executing the target workflow in a container image, reducing the model deployment difficulty and improving the model deployment efficiency.
[0040] In some embodiments, there may be one or multiple model conversion devices. The multiple model conversion devices can be deployed in a distributed manner or a centralized manner. Referring to Figure 1 the model conversion method provided by the embodiments of the present application can be implemented based on Figure 1 a model conversion system as shown. In Figure 1 the model conversion devices a, b, and c are respectively used to process the to-be-deployed model data of different services stored in the data center, that is, the to-be-deployed model data of service A, the to-be-deployed model data of service B, and the to-be-deployed model data of service C. The standardized models to be deployed in the above services can be of the same type or different types. Models of the same type can be converted and deployed using the same or similar workflows, while models of different types need to call their respective corresponding workflows for conversion and deployment. Further optionally, the above services can be batch-converted in parallel through multiple workflows, greatly improving the model deployment efficiency. In practical applications, a single model conversion device can also be used to process the to-be-deployed model data of multiple services, and the embodiments of the present application do not limit this. Among them, the model conversion device can be an application program or a server.
[0041] It should be noted that the server involved in the embodiments of the present application can be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.
[0042] Referring to Figure 2 Figure 2 This is a flowchart illustrating a model conversion method provided in an embodiment of this application. The method can be applied to a model conversion device in a standardized model deployment scenario. Executed by the model conversion device, it achieves automated adaptation between standardized models and different chips in non-standard systems by constructing a target workflow for converting standardized models and executing the target workflow within a container image. The model conversion method includes steps 201-204:
[0043] Step 201: The standardized model to be processed is parsed through the Continuous Integration (CI) system to obtain the standardized configuration information of the standardized model.
[0044] In this application embodiment, a standardized model refers to a machine learning model built, trained, and deployed based on commonly used deep learning model frameworks. For example, the frameworks used in machine learning models include, but are not limited to: Convolutional Architecture for Fast Feature Embedding (Caffe), Open Neural Network Exchange (ONNX), and TensorFlow Lite (TFLite), a symbolic digit system based on dataflow programming. These model frameworks have the following characteristics and uses:
[0045] Caffe is a popular deep learning framework, particularly suitable for image classification and image recognition tasks. It uses hierarchical receptive fields and reusable neural network modules to build and train deep learning models. Caffe provides a relatively simple, flexible, and efficient interface for defining and training models.
[0046] ONNX is an open deep learning model exchange format designed to provide cross-platform and cross-framework model interoperability. Using ONNX, models can be exported from one framework to another and deployed and used for inference on different platforms. ONNX supports various deep learning frameworks, such as PyTorch, TensorFlow, and Caffe2.
[0047] TFLite is a lightweight mobile and embedded deployment solution for TensorFlow. It is optimized for the resource constraints of mobile and embedded devices, providing high-performance model inference capabilities. TFLite supports converting trained TensorFlow models into formats suitable for mobile deployment and provides corresponding interpreters and runtime libraries for model inference.
[0048] The exemplary standard model frameworks described above are widely used in the field of deep learning, providing convenient and efficient solutions for building, training, and deploying machine learning models. Depending on the task requirements and platform characteristics, a suitable machine learning model framework can be selected for model development and application deployment.
[0049] To achieve automated deployment of the standard model, it is necessary to first obtain the standardized configuration information of the standard model to provide a data foundation for the model configuration basic stage in the automated deployment process.
[0050] Step 201 provides an optional implementation method for obtaining the standardized configuration information of the standard model, namely: using the CI system to parse the standard model in order to obtain the standardized configuration information of the standard model.
[0051] In this embodiment, CI system is short for Continuous Integration System. CI system refers to a software development practice that automates the building, testing, and release of code by frequently integrating code into a shared backbone repository, thereby quickly identifying and resolving integration issues and ensuring software quality and stability. CI systems typically consist of tools and processes used to automate the building, testing, and deployment of code. It helps development teams detect and resolve problems faster, reduces the occurrence of integration issues, and improves team efficiency. CI systems are often used in conjunction with version control systems (such as Git), triggering automated build and testing processes upon code commits and promptly notifying the development team of the results. In practical applications, CI systems include Jenkins, Travis CI, and Circle CI, which provide various functions and plugins for customized configuration and management of CI processes to adapt to different project needs and development environments. By using CI systems, development teams can develop software more efficiently while improving software quality and stability.
[0052] Specifically, as an optional embodiment, in step 201, the standardized model to be processed is parsed through the CI system to obtain the standardized configuration information of the standardized model, see [link to relevant documentation]. Figure 3 As shown, this can be specifically implemented through the following steps 301 to 303:
[0053] Step 301: Select a target parser that matches the data source type based on the data source type to which the standardized model belongs.
[0054] The data source type is one of Caffe, TFLite, or ONNX. The steps and methods for obtaining basic model information will differ depending on the model data type (e.g., Caffe, TFLite, ONNX). Below are the specific steps for each model data type:
[0055] Step 302: Load the model file of the standardized model into the target parser;
[0056] Step 303: Extract the model structure and / or parameter configuration information of the standardized model through the target parser.
[0057] The model structure must include at least one of the following: model structure type, model hierarchy, and number of parameters. Parameter configuration information must include at least one of the following: quantization algorithm, quantization precision, and target format.
[0058] For example, when parsing machine learning models from different frameworks, it is necessary to select the appropriate parsing method and configuration information type based on the specific model format and the support of the CI tool. The following will use three common frameworks—Caffe, ONNX, and TensorFlow Lite—as examples to illustrate how to parse standardized models in steps 301 to 303.
[0059] For Caffe models, protobuf files (e.g., .Caffemodel and .prototxt) are used to store network structure and weight parameter information. Therefore, these protobuf files can be parsed using a specified Python interface or third-party library (such as pyCaffe). This allows you to retrieve information such as network layer names, types, input / output dimensions, and model weight parameters from the Caffe model. After loading the Caffe model, you can use the `blobs` attribute of the `Net` class to retrieve all the layers in the model, and the `layers` attribute to retrieve all the layers, along with the name, shape, and number of parameters for each layer.
[0060] For ONNX models, they are stored in .ONNX file format. ONNX models can be loaded using a specified Python interface. Using the ONNX Runtime or other tools supporting the ONNX framework, information such as network nodes, input / output tensor dimensions, and data types can be obtained from the ONNX model. Specifically, the ONNX.load function can be used to load the model and create an ONNX model object. The model's computational graph can be accessed using the model object's graph attribute. Basic model information, including node names, node types, and input / output shapes, can be obtained using the node, input, and output attributes of the computational graph.
[0061] For TensorFlow Lite models, TensorFlow Lite is a lightweight solution for mobile and embedded devices. Therefore, the TFLite parser can be used to load and analyze the model. After loading the TensorFlow Lite model file through a specified Python interface (such as tensorflow-lite), you can use the `get_input_details()` method of the `interpreter` object to retrieve information about the input objects in the TensorFlow Lite model file, including their name, shape, and data type. Similarly, you can use the `get_output_details()` method of the `interpreter` object to retrieve information about the output objects, including their name, shape, and data type. Thus, you can obtain the network's input and output tensor dimensions, data types, etc., from the TensorFlow Lite model.
[0062] The CI system, implemented through steps 301 to 303, parses the standardized model and obtains standardized configuration information. It can select the appropriate target parser based on the data source type of the standardized model, achieving automated processing. This not only improves processing efficiency and accelerates the maintenance, iteration, and release of standardized models, but also ensures the accuracy and completeness of the parsing process, avoiding the loss or error of standardized configuration information. The standardized configuration information allows for a deeper understanding of the standardized model's structure and parameter settings, facilitating automated analysis and optimization. For example, it can examine the model's hierarchical structure, parameter ranges, and input / output specifications to improve model performance and adaptability.
[0063] Furthermore, to meet the task requirements regarding the configuration of quantization conversion information, it is optional to configure model quantization conversion information to provide a data foundation for the subsequent quantization conversion of standardized models. The specific steps for configuring model quantization conversion information are described below for standardized models under frameworks such as Caffe, TFLite, and ONNX:
[0064] For Caffe models, the quantization conversion information is configured using the Caffe tools provided by the deep learning framework or Caffe's built-in API. Optionally, the quantization algorithm, quantization precision, and other parameters can be specified in advance. Specific steps include using Caffe's `Caffe.quantize` function to load the original model and perform the quantization conversion.
[0065] For TFLite models, the TFLite transformer provided by the TensorFlow framework can be used to configure quantization information. For example, the `post_training_quantize` function of the TFLite transformer can be used to configure quantization. When configuring quantization, parameters such as the quantization algorithm, quantization precision, and the input and output ranges can be specified.
[0066] For ONNX models, quantization conversion information can be configured using ONNX Runtime or other frameworks that support ONNX. Specifically, assuming the quantization conversion is configured using the API provided by ONNX Runtime, the ONNX model is loaded and an ONNX model object is created. The QuantizeLinear function provided by ONNX Runtime is then used to perform quantization conversion on the model. When calling the QuantizeLinear function, the quantization precision, quantization algorithm, and other relevant parameters can be specified.
[0067] Of course, in another optional embodiment, step 201, which involves parsing the standard model (such as a machine learning model under Caffe, ONNX, or TFLite) and obtaining standardized configuration information through the CI system, can also be implemented as follows:
[0068] First, select a CI tool compatible with different machine learning models, such as Jenkins, Travis CI, or GitLab CI. Load the selected CI tool to ensure the CI system is connected to the version control system and has build and testing capabilities. Next, based on the different machine learning models, determine the required model parsing method and the types of configuration information to be obtained, and generate the corresponding build script based on these criteria. This build script parses the configuration file of the standard model and extracts the necessary configuration information. Set up a build trigger in the CI tool to trigger the build process at code commits or periodic intervals. This automatically runs the build script and parses the standard model. Then, within the build script, use appropriate parsing tools and libraries to parse the standard model file (such as caffe.proto, ONNXruntime, etc.) and extract the standardized configuration information required for subsequent deployment. For example, information such as the network structure, layer configuration, and dimensions and types of input and output tensors can be obtained. Finally, the CI tool can also automatically run the build script and parse the standardized model, outputting the standardized configuration information to a specified location. After verifying the correctness of the configuration information, the validated standardized configuration information is integrated into subsequent development, testing, or deployment processes. For example, the parsed configuration information can be output to the CI tool's build logs, a specific file in the code repository, or other appropriate locations so that subsequent processes can quickly access this standardized configuration information. Of course, these storage locations are merely examples and are not limited to specific applications. Similar to the previous examples, the specific parsing method can be determined based on the attributes of the standardized model and the support of the CI tool, which will not be elaborated upon here.
[0069] Step 202: Load the standardized model into a container image that matches the standardized configuration information.
[0070] In this embodiment, container images are used to provide a conversion environment for standardized models. It is understood that a container image is an executable software package containing application code, runtime environment, system tools, system libraries, etc. It can run on any platform that supports containerization technology, such as Docker, Kubernetes, etc. Using the same container image allows applications to run in different environments without worrying about differences in environment. Container images have the following characteristics: lightweight, meaning that container images only contain necessary components and dependencies, reducing the size of the container image and improving the speed of startup and deployment; portability, meaning that container images can run in different environments without being limited by specific operating systems or hardware; consistency, meaning that using the same container image can ensure that the application has consistent behavior in different environments; and scalability, meaning that container images can be copied and expanded to meet different needs.
[0071] Alternatively, container images can be created using a Dockerfile in conjunction with Docker or other containerization tools. Once the container image is built, it can be uploaded to an image repository so that subsequent steps can call upon the container image to apply it to the model deployment process.
[0072] As an optional embodiment, loading the standardized model into a container image that matches the standardized configuration information in step 202 can be specifically implemented as follows:
[0073] Obtain the JSON data corresponding to the standardized model based on the data source type; build a container image that matches the JSON data, and load the standardized model into the built container image.
[0074] Continuing with the framework example above, a standardized model with a Caffe data source type matches a Caffe image, which contains command-line tools and interfaces adapted to the Caffe architecture. A standardized model with a TFLite data source type matches a TFLite image, which contains a TFLite converter and a TFLite model interpreter. A standardized model with an ONNX data source type matches an ONNX image, which contains the ONNX Runtime tool, used to load and test ONNX models.
[0075] Specifically, based on different data sources (Caffe, TFLite, ONNX) and their corresponding JSON data, appropriate container images are selected to host the model conversion tools and environments used by these data sources. Below are illustrative examples of container image selection methods for Caffe, TFLite, and ONNX data sources:
[0076] For Caffe data sources, assuming the standardized model to be deployed is a Caffe model, then the Caffe tools need to be used in the container image for model conversion and testing, and the image environment required to install the Caffe model needs to be selected. The specific image selected can be, for example, the official Caffe image or a third-party maintained Caffe image. Within the Caffe image, the command-line tools or Python interface provided by Caffe can be used to load and convert the Caffe model, and the corresponding Caffe model testing tools can be used to conduct various performance tests and other related tests.
[0077] For TFLite data sources, assuming the standardized model to be deployed is a TFLite model, then the TFLite tool needs to be used in the container image for model conversion and testing, and the required image environment for installing the TFLite model needs to be selected. For example, the TFLite image provided by TensorFlow can be used, which includes a TFLite converter and a TFLite model interpreter. In this image environment, the TFLite converter can be used to convert the standardized model to the target format, and the TFLite model interpreter can be used for model testing and inference.
[0078] For ONNX data sources, assuming the standardized model to be deployed is an ONNX model, then it's necessary to use ONNX tools within the container image for model conversion and testing, and select an image environment that installs ONNX Runtime. For example, the official ONNX Runtime image can be used, which includes the ONNX Runtime Python package and command-line tools. Within this image environment, ONNX Runtime tools can be used to load and test the ONNX model, thereby achieving standardized model conversion and inference.
[0079] The above are just examples; the specific image selection method depends on the actual model conversion needs and device environment requirements.
[0080] Having introduced the selectable container images in the above embodiments, the following section describes the steps for building a container image that matches the JSON data, using specific examples. As an optional implementation, see [link to documentation]. Figure 4 The steps to build a container image that matches the JSON data can be implemented as follows:
[0081] Step 401: Create the image configuration file for the container image;
[0082] Step 402: Build a container image based on the image configuration file, and configure the conversion tools and environment parameters required for the model conversion process in the container image.
[0083] The image configuration file includes at least one of the following: data source type, conversion tool, runtime environment information, and dependent libraries. The conversion tool must include at least a specific version of the target driver, and the environment parameters must include at least a specific version of the environment configuration variables and runtime libraries.
[0084] Specifically, first, create a Dockerfile. Create a new text file named Dockerfile. In the Dockerfile, you can specify the base image, such as choosing Ubuntu or another image suitable for the current model conversion needs. In the Dockerfile, use the `RUN` command to install the required packages and tools, such as Python and Shell. You can specify specific versions as needed, for example, `RUN apt-get install -y python3=3.8.10`. If you need to set environment variables, you can use the `ENV` command to specify environment variables in the Dockerfile. For example, `ENV PYTHON_PATH= / usr / bin / python3`.
[0085] Next, build the Docker image. Specifically, you can use the `docker build` command to build a Docker image based on a Dockerfile. The command format is `docker build your_image_name:tag.`, where `your_image_name` is the name of the image, `tag` is the tag to be added to the image, and `.` represents the directory where the Dockerfile is located. During the build process, Docker executes the commands in the Dockerfile, installs the necessary packages and tools, configures environment variables, etc. After the build is complete, you will have a new Docker image containing the necessary environment and tools.
[0086] Next, use the built Docker image. Use the created image by running a Docker container. You can start the container using the `docker run` command. When starting the container, you can use the `-v` option to mount a directory on the host machine into the container so that files on the host machine can be accessed from within the container. For example: `docker run -v / host / path: / container / path your_image_name:tag`. Perform the required model transformation tasks within the container, using the previously configured environment variables and tools.
[0087] This environment configuration scheme allows the necessary model conversion environment and tools to be loaded into the container image, providing a usable environment for the model conversion process. Furthermore, Docker offers a lightweight, portable, and self-contained containerization solution, making the configuration of the model conversion environment more flexible and convenient, avoiding various problems that may exist on non-standard platforms.
[0088] After establishing the necessary environment for model conversion, to further improve the automation and efficiency of model conversion, as well as its deployment efficiency on non-standard platforms, the various steps of converting standardized models can be formalized into a workflow. This workflow can then be used to automatically deploy standardized models to non-standard platforms. Alternatively, a workflow can be used to formalize the model conversion process for one or more model types, enabling the batch deployment of standardized models.
[0089] Step 203: Based on the standardized configuration information, construct the target workflow for converting the standardized model.
[0090] Step 204: Execute the target workflow in the container image to convert the standardized model into a deployment model for deployment on non-standard platforms.
[0091] In this embodiment, the target workflow includes at least the following processes: model format conversion, model quantization, and model compression. The process parameters in the target workflow are determined by the chip configuration on the non-standard platform.
[0092] As an optional embodiment, step 203, which involves constructing a target workflow for converting the standardized model based on standardized configuration information, can be implemented as follows:
[0093] First, create a pipeline project. For example, select a build tool within the container image to create a new pipeline project. The specific creation method depends on the chosen tool or platform, and can typically be done via a graphical interface or command line. After creation, you need to name the project and specify the required configurations, such as repository address and trigger conditions. Next, define the stages and tasks in the pipeline. Define the stages and corresponding tasks required for each step in the pipeline project. Decompose the model transformation process into logically independent tasks. For example, stage a could be model quantization processing, and tasks might include precision setting, data format conversion, etc. Configure the corresponding execution steps for each task, such as generating command-line scripts, calling tools, or running specific programs, to ensure that each task can be executed independently. Furthermore, since the model transformation process needs to follow a certain logical order, it is also necessary to determine the dependencies between tasks, i.e., some tasks must be executed after other tasks are completed, to ensure that tasks are executed in the correct order and that their dependencies are satisfied. Finally, you can set the pipeline's trigger conditions and triggers based on standardized configuration information to clarify when the pipeline execution starts. The triggering conditions can be timed, code committed, or manual; this application does not limit the triggering. After the pipeline process is set up, model testing and verification can be performed to ensure that the model conversion tasks are executed in the defined order and rules, and to ensure that the pipeline can produce the expected model conversion results.
[0094] It's worth noting that the build tools or platform can be further configured to generate task execution logs and reports. This allows for convenient viewing and analysis of the pipeline's execution results. Of course, an alert mechanism can also be configured to receive notifications when errors or anomalies occur. For example, notifications could be sent to the front-end software indicating an anomaly in the model conversion process.
[0095] By following the steps above, you can use an automated build tool or platform suitable for model conversion needs to build a pipeline process, thereby achieving automated and controllable execution of model conversion.
[0096] This application provides a novel model conversion method. By constructing a target workflow for converting standardized models and executing the target workflow in a container image, the method achieves automated adaptation between standardized models and different chips in non-standard systems, reducing the difficulty of model deployment and improving the efficiency of model deployment.
[0097] As an optional embodiment, after step 204, it is also possible to detect whether an automatic deployment trigger event has occurred. The automatic deployment trigger event includes at least one of the following: adding a new dataset, adding a new data model, the model training accuracy reaching a set threshold, the model training loss decreasing to a set threshold, reaching the model's corresponding release cycle, model version update, a preset change in the model timestamp, version change conditions, or a preset change in the data source. Furthermore, if the automatic deployment trigger event occurs, the target workflow is re-executed in the container image to initiate the conversion process for the newly obtained standardized model.
[0098] Understandably, when an automatic deployment trigger event is met, the standardized model conversion process is automatically initiated, converting the newly acquired model into a deployable container image. This further reduces the workload of manual deployment, improving deployment efficiency and speed. Specifically, by monitoring events and re-executing the conversion process, it ensures that the model in the container image is always the latest version. When the dataset, model, or other relevant conditions change, the conversion process is automatically re-executed to maintain model consistency with the latest data and requirements. By setting thresholds for training accuracy, loss, etc., automatic deployment is triggered only when the model training reaches the expected performance, helping to ensure that the deployed model has the required accuracy and performance, avoiding the deployment of low-quality models. Furthermore, automatic deployment can scale the number of container image instances as needed to meet high traffic and high load demands. Rapid scaling when a new model is deployed and scaling down as needed provide resilience and high availability.
[0099] In this embodiment, by detecting automatic deployment trigger events and re-executing the target workflow, the model conversion and deployment process can be automated, ensuring that the model is always the latest container image with the expected performance. This improves deployment efficiency, accuracy, and performance control, and also provides a way to elastically scale, further enhancing the flexibility of non-standard platforms.
[0100] As an optional embodiment, after step 204, the converted deployment model is further subjected to testing and verification. This testing and verification includes model performance testing and / or accuracy verification. Furthermore, after testing and verification, the deployment model is subjected to inference verification to verify its usability on non-standard platforms.
[0101] It's worth noting that model performance testing allows for the evaluation of performance metrics such as speed and memory usage on non-standard platforms, effectively assessing the model's suitability and resource consumption in real-world deployment environments. This enables adjustments and optimizations based on specific needs. Accuracy verification, on the other hand, evaluates the model's accuracy and predictive capabilities on non-standard platforms. Since model performance may vary across different hardware, operating systems, or library versions, accuracy verification ensures optimal model performance on non-standard platforms and provides relatively reliable prediction results. Furthermore, during the inference verification phase, usability verification verifies the model's usability on non-standard platforms. This includes verifying the model's predictive performance in real-world scenarios, as well as its stability and reliability. Testing and verification confirm that the model can correctly process input data and generate accurate output. Alternatively, error detection and debugging can be performed, allowing for the resolution of potential errors and issues through testing and verification. Through model performance testing and accuracy verification, potential performance bottlenecks, erroneous outputs, or other problems can be identified and addressed promptly.
[0102] In this embodiment of the application, testing and verification of the converted deployment model helps to evaluate the model's performance, accuracy, and usability, provides an opportunity to comprehensively examine the performance of the deployment model on non-standard platforms, and helps to ensure the quality and reliability of the deployment model.
[0103] As an optional embodiment, after step 204, the deployment model information is output as a notification message to inform the model publisher that the model has been deployed to a non-standard platform. This facilitates user viewing and verification. The deployment model information includes, but is not limited to: model version, version management instructions, release notes, associated project management instructions, test results, project information, and historical version information.
[0104] It's easy to understand that outputting deployment model information in the form of notification messages allows users to more conveniently access and view the model through a browser, without the need for additional installation or configuration. For example, users can view the model's structure, parameters, and other relevant information through the notification message interface, as well as test and validate the model. By outputting deployment model information in the form of notification messages, the characteristics and performance of the model are understood intuitively, improving the interactivity and visualization of the model deployment process. Through notification messages, users can receive timely updates on the deployment status and related information of the model. This also helps users understand the deployment status of the model on non-standard platforms in a timely manner and make timely adjustments and adjustments. Notification messages also allow users to receive timely notifications of the deployment of the model without manual checking and confirmation, improving the efficiency of model deployment and enabling users to push the model to non-standard platforms for use more quickly. Of course, this approach also ensures data transparency; non-authorized users can learn about the model's detailed information through the notification message interface, while the model publisher can track and monitor the deployment process through message notifications.
[0105] In this embodiment, the deployment model information is output in the form of a notification message, which helps to provide a convenient user experience, quick notification release, and a visual and transparent display method, thereby improving the efficiency of model use and deployment.
[0106] In addition, each model conversion step described in the above embodiments can be presented to the user through Lark or other notification messages, so that the user can monitor the model conversion process through visual model conversion progress information, promptly detect any anomalies that may occur during the model conversion process, and improve the efficiency of model use and release.
[0107] After introducing the method of the embodiments of this application, the following references are made. Figure 5 The model conversion apparatus of the present application embodiments will be described.
[0108] The model conversion device 50 in this embodiment can achieve the corresponding to the above-mentioned... Figure 2 The steps of the model conversion method in the corresponding embodiment are described. The functions implemented by the model conversion device 50 can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions, and the modules can be software and / or hardware. The model conversion device 50 may include a parsing module 501, a loading module 502, a construction module 503, and an execution module 504. The functional implementation of these modules can be found in [reference needed]. Figure 2 The operations performed in the corresponding embodiments will not be described in detail here.
[0109] In some implementations, the parsing module 501 is configured to parse the standardized model to be processed through the CI system to obtain the standardized configuration information of the standardized model;
[0110] Loading module 502 is configured to load the standardized model into a container image that matches the standardized configuration information; wherein the container image is used to provide a conversion environment for the standardized model;
[0111] The construction module 503 is configured to construct a target workflow for converting the standardized model based on the standardized configuration information; the target workflow includes at least the following processes: model format conversion, model quantization, and model compression; the process parameters in the target workflow are determined by the chip configuration on the non-standard platform.
[0112] Execution module 504 is configured to execute the target workflow in the container image to convert the standardized model into a deployment model for deployment on a non-standard platform.
[0113] In some implementations, when the parsing module 501 parses the standardized model to be processed through the CI system to obtain the standardized configuration information of the standardized model, it is configured as follows:
[0114] Based on the data source type to which the standardized model belongs, select a target parser that matches the data source type; the data source type is one of Caffe, TFLite, or ONNX;
[0115] The model file of the standardized model is loaded into the target parser;
[0116] The target parser extracts the model structure and / or parameter configuration information of the standardized model.
[0117] The model structure includes at least one of the following: model structure type, model hierarchy, and number of parameters; the parameter configuration information includes at least one of the following: quantization algorithm, quantization accuracy, and target format.
[0118] In some implementations, when the loading module 502 loads the standardized model into a container image that matches the standardized configuration information, it is configured to:
[0119] Retrieve the JSON data corresponding to the standardized model based on the data source type;
[0120] Build a container image that matches the JSON data, and load the standardized model into the built container image;
[0121] Specifically, the standardized model with Caffe as its data source type matches the Caffe image, which loads command-line tools and interfaces adapted to the Caffe architecture; the standardized model with TFLite as its data source type matches the TFLite image, which loads the TFLite converter and TFLite model interpreter; and the standardized model with ONNX as its data source type matches the ONNX image, which loads the ONNXRuntime tool, used to load and test ONNX models.
[0122] In some implementations, the loading module 502, when building a container image that matches the JSON data, is configured as follows:
[0123] Create a container image configuration file; the image configuration file includes at least one of the following: data source type, transformation tool, runtime environment information, and dependency libraries;
[0124] The container image is built based on the image configuration file, and the conversion tools and environment parameters required for the model conversion process are configured in the container image.
[0125] The conversion tool includes at least a specific version of the target driver, and the environment parameters include at least a specific version of the environment configuration variables and runtime library.
[0126] In some embodiments, the device further includes a detection module, which is also configured to:
[0127] After the execution module 504 executes the target workflow in the container image to convert the standardized model into a deployment model for release on a non-standard platform, it detects whether an automatic deployment trigger event has occurred. The automatic deployment trigger event includes at least one of the following: adding a new dataset, adding a new data model, the accuracy of model training reaching a set threshold, the loss of model training decreasing to a set threshold, reaching the release cycle corresponding to the model, model version update, a preset change in model timestamp, version change conditions, or a preset change in data source. If the automatic deployment trigger event occurs, the target workflow is re-executed in the container image to start the conversion process for the newly obtained standardized model.
[0128] In some embodiments, the device further includes a detection module, which is also configured to:
[0129] After the execution module 504 executes the target workflow in the container image to convert the standardized model into a deployment model for deployment on a non-standard platform, the converted deployment model is subjected to testing and verification processing. The testing and verification processing includes model performance testing and / or accuracy verification. After testing and verification, the deployment model is subjected to inference verification to verify the usability of the deployment model on the non-standard platform.
[0130] In some embodiments, the device further includes a detection module, which is also configured to:
[0131] After the execution module 504 executes the target workflow in the container image to convert the standardized model into a deployment model for publication on a non-standard platform, the deployment model information is output in the form of a notification message to inform the model publisher that the deployment model has been published to the non-standard platform.
[0132] In this embodiment, the model conversion device can achieve automated adaptation between standardized models and different chips in non-standard systems by constructing a target workflow for converting standardized models and executing the target workflow in a container image, thereby reducing the difficulty of model deployment and improving the efficiency of model deployment.
[0133] After introducing the methods and apparatus of the embodiments of this application, the computer-readable storage medium of the embodiments of this application will now be described. The computer-readable storage medium may be an optical disc, on which a computer program (i.e., a program product) is stored. When the computer program is run by a processor, it will implement the steps described in the above-described method embodiments. For example, it will parse the standardized model to be processed through a continuous integration system to obtain the standardized configuration information of the standardized model; load the standardized model into a container image that matches the standardized configuration information; the container image will be used to provide a conversion environment for the standardized model; construct a target workflow for converting the standardized model according to the standardized configuration information; the target workflow will include at least the following processes: model format conversion, model quantization, and model compression; the process parameters in the target workflow will be determined by the chip configuration carried in the non-standard platform; and execute the target workflow in the container image to convert the standardized model into a deployment model for deployment on the non-standard platform. The specific implementation of each step will not be repeated here.
[0134] It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.
[0135] The model conversion device 50 in this application embodiment has been described above from the perspective of modular functional entities. The server and terminal device for executing the model conversion method in this application embodiment are described below from the perspective of hardware processing.
[0136] It should be noted that the model conversion device embodiment of this application may also include a transceiver module, which is used for data transmission. The physical device corresponding to the transceiver module may be an input / output unit, a transceiver, a radio frequency circuit, a communication module, and an input / output (I / O) interface, etc. The physical devices corresponding to the parsing module, loading module, construction module, and execution module may be processors. Figure 5 The model conversion device 50 shown can have, for example, Figure 6 The structure shown, when Figure 5 The model conversion device 50 shown has, for example, Figure 6 When the structure shown is used, Figure 6 The processor and transceiver in the device can perform the same or similar functions as the modules provided in the aforementioned device embodiments. Figure 6 The memory storage processor in the memory needs to call the computer program when executing the above model conversion method.
[0137] Figure 7 This is a schematic diagram of a server structure provided in an embodiment of this application. The server 1100 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 1122 (e.g., one or more processors) and memory 1132, and one or more storage media 1130 (e.g., one or more mass storage devices) for storing application programs 1142 or data 1144. The memory 1132 and storage media 1130 can be temporary or persistent storage. The program stored in the storage media 1130 may include one or more modules (not shown in the figure), each module may include a series of instruction operations on the server. Furthermore, the CPU 1122 may be configured to communicate with the storage media 1130 and execute the series of instruction operations in the storage media 1130 on the server 1100.
[0138] Server 1100 may also include one or more power supplies 1126, one or more wired or wireless network interfaces 1150, one or more input / output interfaces 1158, and / or one or more operating systems 1141, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc.
[0139] The steps performed by the server in the above embodiments can be based on this Figure 7 The structure of server 1100 shown. For example, as in the above embodiment, by Figure 7 The steps performed by the model conversion device 60 shown can be based on this Figure 7 The server structure is shown. For example, the central processing unit 1122 performs the following operations by calling instructions from memory 1132:
[0140] The standardized model to be processed is parsed through the continuous integration system via input / output interface 1158 to obtain the standardized configuration information of the standardized model; the standardized model is loaded into a container image that matches the standardized configuration information; the container image is used to provide a conversion environment for the standardized model; based on the standardized configuration information, a target workflow for converting the standardized model is constructed; the target workflow includes at least the following processes: model format conversion, model quantization, and model compression; the process parameters in the target workflow are determined by the chip configuration on the non-standard platform; the target workflow is executed in the container image to convert the standardized model into a deployment model for release on the non-standard platform.
[0141] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.
[0142] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0143] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, apparatuses, or modules, and may be electrical, mechanical, or other forms.
[0144] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.
[0145] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium.
[0146] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.
[0147] The computer program product includes one or more computer instructions. When the computer program is loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state disk (SSD)).
[0148] The technical solutions provided in the embodiments of this application have been described in detail above. Specific examples have been used in the embodiments of this application to illustrate the principles and implementation methods of the embodiments of this application. The description of the above embodiments is only for the purpose of helping to understand the methods and core ideas of the embodiments of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the embodiments of this application. Therefore, the content of this specification should not be construed as a limitation on the embodiments of this application.
Claims
1. A model conversion method, characterized in that, The method includes: The standardized model to be processed is parsed by a continuous integration (CI) system to obtain the standardized configuration information of the standardized model, including: selecting a target parser that matches the data source type to which the standardized model belongs; the data source type is one of Caffe, TFLite, and ONNX; loading the model file of the standardized model into the target parser; and extracting the model structure and / or parameter configuration information of the standardized model through the target parser; wherein, the model structure includes at least one of the following: model structure type, model hierarchy, and number of parameters; and the parameter configuration information includes at least one of the following: quantization algorithm, quantization precision, and target format. Loading the standardized model into a container image that matches the standardized configuration information includes: obtaining JSON data corresponding to the standardized model according to the data source type; constructing a container image that matches the JSON data, and loading the standardized model into the constructed container image; wherein, the container image is used to provide a conversion environment for the standardized model; the standardized model with the data source type of Caffe matches the Caffe image, which loads command-line tools and interfaces adapted to the Caffe architecture; the standardized model with the data source type of TFLite matches the TFLite image, which loads the TFLite converter and TFLite model interpreter; the standardized model with the data source type of ONNX matches the ONNX image, which loads the ONNXRuntime tool, which is used to load and test the ONNX model; Based on the standardized configuration information, a target workflow for converting the standardized model is constructed; the target workflow includes at least the following processes: model format conversion, model quantization, and model compression; the process parameters in the target workflow are determined by the chip configuration on the non-standard platform. The target workflow is executed within the container image to convert the standardized model into a deployment model for deployment on non-standard platforms.
2. The method as described in claim 1, characterized in that, The construction of the container image matching the JSON data includes: Create a container image configuration file; the image configuration file includes at least one of the following: data source type, transformation tool, runtime environment information, and dependency libraries; The container image is built based on the image configuration file, and the conversion tools and environment parameters required for the model conversion process are configured in the container image. The conversion tool includes at least a specific version of the target driver, and the environment parameters include at least a specific version of the environment configuration variables and runtime library.
3. The method as described in claim 1, characterized in that, After executing the target workflow in the container image to convert the standardized model into a deployment model for deployment on a non-standard platform, the process further includes: Detect whether an automatic deployment trigger event has occurred; the automatic deployment trigger event includes at least one of the following: adding a new dataset, adding a new data model, the accuracy of model training reaching a set threshold, the loss of model training decreasing to a set threshold, reaching the release cycle corresponding to the model, model version update, a preset change in model timestamp, version change conditions, or a preset change in data source; If the automatic deployment trigger event occurs, the target workflow is re-executed in the container image to initiate the conversion process to the newly obtained standardized model.
4. The method as described in claim 1, characterized in that, After executing the target workflow in the container image to convert the standardized model into a deployment model for deployment on a non-standard platform, the process further includes: The converted deployment model is subjected to testing and verification processes; these processes include model performance testing and / or accuracy verification. After testing and verification, the deployment model is inference-based to verify its usability on non-standard platforms.
5. The method as described in claim 1, characterized in that, After executing the target workflow in the container image to convert the standardized model into a deployment model for deployment on a non-standard platform, the process further includes: The deployment model information is output as a notification message to inform the model publisher that the deployment model has been published to a non-standard platform.
6. A model conversion device, characterized in that, The device includes: The parsing module is configured to parse the standardized model to be processed through the CI system to obtain the standardized configuration information of the standardized model; The parsing module, when parsing the standardized model to be processed through the CI system to obtain the standardized configuration information of the standardized model, is configured to: select a target parser that matches the data source type to which the standardized model belongs; the data source type is one of Caffe, TFLite, and ONNX; load the model file of the standardized model into the target parser; and extract the model structure and / or parameter configuration information of the standardized model through the target parser; wherein, the model structure includes at least one of the following: model structure type, model hierarchy, and number of parameters; and the parameter configuration information includes at least one of the following: quantization algorithm, quantization precision, and target format. A loading module is configured to load the standardized model into a container image that matches the standardized configuration information; wherein the container image is used to provide a conversion environment for the standardized model. The loading module, when loading the standardized model into a container image matching the standardized configuration information, is configured to: obtain JSON data corresponding to the standardized model based on the data source type; construct a container image matching the JSON data; and load the standardized model into the constructed container image. Specifically, the standardized model with a Caffe data source type matches the Caffe image, which contains command-line tools and interfaces adapted to the Caffe architecture; the standardized model with a TFLite data source type matches the TFLite image, which contains a TFLite converter and a TFLite model interpreter; and the standardized model with an ONNX data source type matches the ONNX image, which contains the ONNX Runtime tool, used to load and test ONNX models. The building module is configured to construct a target workflow for converting the standardized model based on the standardized configuration information; the target workflow includes at least the following processes: model format conversion, model quantization, and model compression; the process parameters in the target workflow are determined by the chip configuration on the non-standard platform. An execution module is configured to execute the target workflow in the container image to convert the standardized model into a deployment model for deployment on a non-standard platform.
7. A computing device, comprising 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, it implements the method of any one of claims 1-5.
8. A computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-5.