CN117453237A - 模型转换方法以及相关装置 - Google Patents

Abstract

本申请实施例涉及数据处理领域，提供一种模型转换方法以及相关装置。该方法：通过持续集成***解析待处理的标准化模型，以得到标准化模型的标准化配置信息；将标准化模型加载到与标准化配置信息匹配的容器镜像中；容器镜像用于为标准化模型提供转换环境；根据标准化配置信息，构建用于转换标准化模型的目标工作流；目标工作流至少包括以下流程：模型格式转换、模型量化、模型压缩；目标工作流中的流程参数由非标准平台中搭载的芯片配置决定；在容器镜像中执行目标工作流，以使标准化模型转换为用于在非标准平台发布的部署模型。该方法能够实现标准化模型与非标准***中不同芯片之间的自动化适配处理，降低模型部署难度，提升模型部署效率。

Description

模型转换方法以及相关装置

技术领域

本申请实施例涉及数据处理领域，更具体地涉及一种模型转换方法以及相关装置。

背景技术

人工智能在多个复杂场景中得到广泛应用，这依赖于日趋成熟的国产化芯片解决方案。

在芯片国产化的浪潮中，虽然越来越多的国产芯片问世并投入使用，但与这些芯片配套的应用工具却缺乏一致性，难以应对各种芯片之间的差异。然而，不同厂家的设备以及芯片部署逻辑存在差异，使得标准化模型部署过程中还需要根据***后端所使用的不同芯片进行适配，部署难度大，部署效率低。此外，由于不同芯片的维护方式有区别，因而，后端芯片类型增加，还会进一步导致维护难度加剧。

综上，亟待设计一种全新的技术方案，用以解决标准化模型与非标准***中不同芯片之间的适配问题，降低模型部署难度，提升模型部署效率。

发明内容

本申请实施例提供一种模型转换方法以及相关装置，能够实现标准化模型与非标准***中不同芯片之间的自动化适配处理，降低模型部署难度，提升模型部署效率。

第一方面，本申请实施例提供一种模型转换方法，该方法包括：

通过持续集成(Continuous Integration，CI)***解析待处理的标准化模型，以得到标准化模型的标准化配置信息；

将标准化模型加载到与标准化配置信息匹配的容器镜像中；其中，容器镜像用于为标准化模型提供转换环境；

根据标准化配置信息，构建用于转换标准化模型的目标工作流；目标工作流至少包括以下流程：模型格式转换、模型量化、模型压缩；目标工作流中的流程参数由非标准平台中搭载的芯片配置决定；

在容器镜像中执行目标工作流，以使标准化模型转换为用于在非标准平台发布的部署模型。

第二方面，本申请实施例提供一种模型转换装置，具有实现对应于上述第一方面提供的模型转换方法的功能。功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，模块可以是软件和/或硬件。在一个实施方式中，该装置包括：

解析模块，被配置为通过CI***解析待处理的标准化模型，以得到标准化模型的标准化配置信息；

加载模块，被配置为将标准化模型加载到与标准化配置信息匹配的容器镜像中；其中，容器镜像用于为标准化模型提供转换环境；

构建模块，被配置为根据标准化配置信息，构建用于转换标准化模型的目标工作流；目标工作流至少包括以下流程：模型格式转换、模型量化、模型压缩；目标工作流中的流程参数由非标准平台中搭载的芯片配置决定；

执行模块，被配置为在容器镜像中执行目标工作流，以使标准化模型转换为用于在非标准平台发布的部署模型。

第三方面，本申请实施例提供一种计算设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现第一方面中所述的模型转换方法。

第四方面，本申请实施例提供一种计算机可读存储介质，其包括指令，当其在计算机上运行时，使得计算机执行第一方面中所述的模型转换方法。

第五方面，本申请实施例提供一种芯片，该芯片中包括与终端设备的收发器耦合的处理器，用于执行本申请实施例第一方面提供的技术方案。

第六方面，本申请实施例提供一种芯片***，该芯片***包括处理器，用于支持终端设备实现上述第一方面中所涉及的功能，例如，生成或者处理上述第一方面提供的方法中所涉及的信息。

在一种可能的设计中，上述芯片***还包括存储器，该存储器用于保存终端必需的程序指令和数据。该芯片***可以由芯片构成，也可以包含芯片和其他分立器件。

第七方面，本申请实施例提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第一方面提供的方法。

相较于相关技术，本申请实施例中，通过CI***解析待处理的标准化模型，以得到标准化模型的标准化配置信息。通过解析标准化模型，可以获得标准化配置信息，包括模型的架构、层次结构、输入输出格式等。这些信息能够为后续构建模型转换流程以及相应的部署流程提供数据基础。进而，将标准化模型加载到与标准化配置信息匹配的容器镜像中，该容器镜像用于为标准化模型提供转换环境。通过容器镜像可以隔离标准化模型的运行环境，从而保证为标准化模型的运行环境的一致性，使得标准化模型转换过程对于不同非标平台具有可重复性和可移植性，确保标准化模型在不同非标平台上能够以同一方式进行转换和部署。接着，根据标准化配置信息，构建用于转换标准化模型的目标工作流；进而，在容器镜像中执行目标工作流，以使标准化模型转换为用于在非标准平台发布的部署模型。这里，目标工作流至少包括以下流程：模型格式转换、模型量化、模型压缩。本申请中的目标工作流，可以根据不同标准化模型的部署需求进行自动化定制，包括模型的数据转换、模型压缩、优化等流程以及相关参数，从而确保标准化模型能够高效移植到非标准平台中。可以理解的是，目标工作流中的流程参数由非标准平台中搭载的芯片配置决定。这样，根据非标准平台中搭载的芯片配置，动态调整目标工作流中的流程参数，能够最大程度使模型匹配到非标平台的性能和特性，这种灵活性可以确保模型在非标准平台上获得最佳的性能和效果。

相比于相关技术，本申请实施例中提供了一种全新的模型转换方式，通过构建用于转换标准化模型的目标工作流，并在容器镜像中执行目标工作流实现标准化模型与非标准***中不同芯片之间的自动化适配处理，降低模型部署难度，提升模型部署效率。

附图说明

通过参考附图阅读本申请实施例的详细描述，本申请实施例的目的、特征和优点将变得易于理解。其中：

图1为本申请实施例中模型转换***的一种示意图；

图2为本申请实施例中模型转换方法的一种流程示意图；

图3为本申请实施例中模型解析方法的一种流程示意图；

图4为本申请实施例中容器镜像构建方法的一种流程示意图；

图5为本申请实施例中模型转换装置的一种结构示意图；

图6为本申请实施例中计算设备的一种结构示意图；

图7为本申请实施例中服务器的一种结构示意图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

本申请实施例的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或模块的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或模块，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或模块，本申请实施例中所出现的模块的划分，仅仅是一种逻辑上的划分，实际应用中实现时可以有另外的划分方式，例如多个模块可以结合成或集成在另一个***中，或一些特征可以忽略，或不执行。另外，所显示的或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，模块之间的间接耦合，通信连接可以是电性或其他类似的形式，本申请实施例中均不作限定。并且，作为分离部件说明的模块或子模块可以是也可以不是物理上的分离，可以是也可以不是物理模块，或者可以分布到多个电路模块中，可以根据实际的需要选择其中的部分或全部模块来实现本申请实施例方案的目的。

本申请实施例提供一种模型转换方法，可应用于标准化模型部署场景，涉及至少一服务设备，至少一服务设备包括至少一个模型转换装置。例如，一个服务设备包括一个模型转换装置，用于执行模型转换中不同阶段的步骤。例如，模型转换装置用于构建用于转换标准化模型的目标工作流，并在容器镜像中执行目标工作流实现标准化模型与非标准***中不同芯片之间的自动化适配处理，降低模型部署难度，提升模型部署效率。其中，模型转换装置可为构建用于转换标准化模型的目标工作流，并在容器镜像中执行目标工作流实现标准化模型与非标准***中不同芯片之间的自动化适配处理的应用程序，或为安装了构建用于转换标准化模型的目标工作流，并在容器镜像中执行目标工作流实现标准化模型与非标准***中不同芯片之间的自动化适配处理的应用程序的服务器。

本申请实施例提供的方案涉及云原生、容器等概念，具体参见如下介绍:

云原生，是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。其中，云原生应用，也就是面向“云”而设计的应用，在使用云原生技术后，开发者无需考虑底层的技术实现，可以充分发挥云平台的弹性和分布式优势，实现快速部署、按需伸缩、不停机交付等。

容器，是一种开源的容器化平台，可以帮助开发者将应用程序及其依赖项打包到可移植的容器中。容器是一种轻量级、可隔离和可移植的运行环境，包含了应用程序所需的所有组件(例如代码、运行时、库和***工具)。容器化使应用程序能够在任何环境中以一致的方式运行，无论是开发、测试、部署到生产环境还是移植到其他云平台。Docker，提供了一个容器镜像的概念，是一个可执行的软件包，包含了运行容器所需的所有内容，包括代码、运行时、***工具、库以及配置信息。容器镜像是可移植的，可以在不同的主机上进行部署和共享。通过使用Docker，可以实现快速、一致和可靠的应用程序交付和部署，减少了开发人员与运维人员之间的摩擦，并提高了***的可移植性、可扩展性和资源利用率。

相关技术中的标准化模型部署场景下，待部署平台中通常搭载有多种不同芯片，多种芯片配套的应用工具却缺乏一致性，难以应对各种芯片之间的差异，使得标准化模型部署过程中还需要根据***后端所使用的不同芯片进行适配，部署难度大，部署效率低。此外，由于不同芯片的维护方式有区别，因而，后端芯片类型增加，还会进一步导致维护难度加剧。

相比于相关技术中为不同芯片分别进行人工的平台部署方案，本申请实施例提供一种模型转换方案，能够通过构建用于转换标准化模型的目标工作流，并在容器镜像中执行目标工作流实现标准化模型与非标准***中不同芯片之间的自动化适配处理，降低模型部署难度，提升模型部署效率。

一些实施方式中，模型转换装置是一个，也可以是多个。多个模型转换装置可以采用分布式部署，也可以采用集中式部署，参照图1，本申请实施例提供的模型转换方法可基于图1所示的一种模型转换***实现。在图1中，模型转换装置a、b、c分别用于处理数据中心所存储的不同业务的待部署模型数据，即业务A的待部署模型数据、业务B的待部署模型数据、业务C的待部署模型数据。上述业务中待部署的标准化模型可以是同一类型，也可以是不同类型。同一类型的模型可采用相同或相似的工作流进行转换以及部署，而不同类型的模型则需调用各自对应的工作流进行转换以及部署。进一步可选地，上述业务可以通过多个工作流实现并行批量转换，大大提升模型部署效率。实际应用中，一个模型转换装置也可用于处理多个业务的待部署模型数据，本申请实施例并不限制。其中，模型转换装置可以是应用程序、服务器。

需要说明的是，本申请实施例涉及的服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

参照图2，图2为本申请实施例提供的一种模型转换方法的流程示意图。该方法可应用于标准化模型部署场景下的模型转换装置，由模型转换装置执行，通过构建用于转换标准化模型的目标工作流，并在容器镜像中执行目标工作流实现标准化模型与非标准***中不同芯片之间的自动化适配处理的具体步骤。所述模型转换方法包括步骤201-204：

步骤201，通过持续集成(Continuous Integration，CI)***解析待处理的标准化模型，以得到标准化模型的标准化配置信息。

在本申请实施例中，标准化模型是指基于常用的深度学习模型框架，构建、训练以及部署的机器学习模型。比如，机器学习模型应用的框架包括但不限于：快速特征嵌入的卷积架构(Convolutional Architecture for Fast Feature Embedding，Caffe)、开放神经网络交换(Open Neural Network Exchange，ONNX)、基于数据流编程的符号数字***(TensorFlow Lite，TFLite)。这些模型框架具有以下特点和用途：

其中，Caffe，是一个流行的深度学习框架，特别适用于图像分类和图像识别任务。它使用了层次化感受野和可重复使用的神经网络模块来构建和训练深度学习模型。Caffe提供了相对简单、灵活和高效的接口来定义和训练模型。

ONNX，是一个开放的深度学***台和跨框架的模型互操作性。通过使用ONNX，可以将模型从一个框架导出到另一个框架，并在不同的平台上部署和推理。ONNX支持多种深度学习框架，如PyTorch、TensorFlow、Caffe2等。

TFLite，是TensorFlow的轻量级移动和嵌入式端部署解决方案。它针对移动设备和嵌入式设备的资源限制进行了优化，提供了高性能的模型推理功能。TFLite支持将训练好的TensorFlow模型转换为适合移动端部署的格式，并提供相应的解释器和运行时库用于模型的推理。

上述介绍的几种示例性的标准模型框架，在深度学***台特点，可以选择适合的机器学习模型框架，进行模型开发和应用部署。

为了实现标准模型的自动化部署，需要先获取标准模型的标准化配置信息，为自动化部署过程中的模型配置基础阶段提供数据基础。

步骤201中提供了一种可选实现方式，用于获取标准模型的标准化配置信息，即：采用CI***对标准模型进行解析，以获取标准模型的标准化配置信息。

本申请实施例中，CI***是持续集成***(Continuous Integration System)的简称。CI***是指一种软件开发的实践方法，通过频繁地集成代码到共享的主干版本库，进行自动化构建、测试和发布，来快速发现和解决集成问题，确保软件质量和稳定性。CI***通常由一些工具和流程组成，用于自动化构建、测试和部署代码。它能够帮助开发团队更快地检测和解决问题，减少集成问题的出现，提高团队工作效率。CI***通常与版本控制***(如Git)结合使用，可以在代码提交时触发自动化构建和测试过程，并将结果及时通知开发团队。实际应用中，CI***包括Jenkins、Travis CI、CircleCI等，它们提供了各种功能和插件，以便定制化地配置和管理CI流程，从而适应不同的项目需求和开发环境。通过使用CI***，开发团队可以更加高效地进行软件开发，同时提高软件的质量和稳定性。

具体而言，作为一个可选的实施例，步骤201中通过CI***解析待处理的标准化模型，以得到所述标准化模型的标准化配置信息，参见图3所示，可以具体实现为以下步骤301至303：

步骤301，根据标准化模型所属的数据源类型，选择与数据源类型匹配的目标解析器。

其中，数据源类型为Caffe、TFLite、ONNX中的一种。对于不同的模型数据类型(例如Caffe、TFLite、ONNX)，获取模型的基本信息的步骤和方法会有所不同。下面是针对每种模型数据类型的具体步骤：

步骤302，将标准化模型的模型文件加载到目标解析器中；

步骤303，通过目标解析器提取标准化模型的模型结构和/或参数配置信息。

其中，模型结构至少包括以下中的一种：模型结构类型、模型层次、参数量。参数配置信息至少包括以下中的一种：量化算法、量化精度、目标格式。

举例来说，当根据不同框架的机器学习模型进行解析时，需要根据具体的模型格式和CI工具的支持情况选择相应的解析方式和配置信息类型。下面将以三种常见的框架，即Caffe、ONNX、TensorFlow Lite为例，介绍在步骤301到303中如何对标准化模型进行解析。

对于Caffe模型而言，Caffe模型使用protobuf文件(例如.Caffemodel和.prototxt)来存储网络结构和权重参数信息。因此，可以使用指定的Python接口或第三方库(如pyCaffe)解析这些protobuf文件。并从Caffe模型中获取网络层的名称、类型、输入输出的维度信息、模型权重参数等。加载Caffe模型后，使用Net类的blobs属性可以获取模型中所有的层次(blobs)，使用layers属性可以获取模型中所有的层以及每个层的名称、形状、参数数量。

对于ONNX模型而言，ONNX模型以.ONNX文件格式进行存储。可以使用指定的Python接口加载ONNX模型。并使用ONNX Runtime或其他支持ONNX框架的工具，从ONNX模型中获取网络的节点(Node)信息、输入输出张量的维度信息、数据类型等信息。具体来说，可以使用ONNX.load函数可以加载模型并创建ONNX模型对象。使用模型对象的graph属性可以访问模型的计算图。使用计算图的节点、输入和输出属性可以获取模型的基本信息，包括节点名称、节点类型、输入输出形状等。

对于TensorFlow Lite模型而言，TensorFlow Lite是一个用于移动和嵌入式设备的轻量级解决方案。因此，可以使用TFLite解析器来加载和分析模型。通过指定的Python接口(如tensorflow-lite)加载TensorFlow Lite模型文件之后，可以使用interpreter对象的get_input_details()方法可以获取TensorFlow Lite模型文件中输入对象的信息，包括名称、形状和数据类型，也可以使用interpreter对象的get_output_details()方法可以获取输出对象的信息，包括名称、形状和数据类型。从而，从TensorFlow Lite模型中可以获取网络的输入输出张量维度、数据类型等。

通过步骤301至303实现的CI***解析标准化模型并获取标准化配置信息，能够根据标准化模型的数据源类型选择相应的目标解析器，实现自动化处理流程，不仅提高处理效率，加速标准化模型的维护、迭代和发布，还可以保证解析过程的准确性和完整性，避免标准化配置信息的丢失或错误。通过标准化配置信息可以深入理解标准化模型的结构和参数设置，有助于对标准化模型进行自动化分析和优化。例如，可以检查模型的层次结构、参数范围、输入输出规范等，以提高模型性能和适应性。

此外，为满足在配置量化转换相关信息方面的任务需求，进一步可选地，配置模型量化转换信息，以便为后续标准化模型的量化转换提供数据基础。下面分别针对Caffe、TFLite和ONNX等框架下的标准化模型，介绍配置模型量化转换信息的具体步骤，即：

对于Caffe模型，采用深度学习框架提供的Caffe工具或Caffe自带的API来配置量化转换信息。可选地，量化算法、量化的精度和其他参数可以是预先指定的。具体的步骤包括使用Caffe的Caffe.quantize函数来加载原始模型并完成量化转换。

对于TFLite模型，可以使用TensorFlow框架提供的TFLite转换器来配置量化转换信息。例如，采用TFLite转换器的post_training_quantize函数来配置量化转换。在配置量化转换时，指定量化算法、量化的精度、量化的输入和输出范围等参数。

对于ONNX模型，可以使用ONNX Runtime或其他支持ONNX的框架来配置量化转换信息。具体而言，假设采用ONNX Runtime提供的API来配置量化转换，基于此，加载ONNX模型并创建ONNX模型对象，使用ONNX Runtime提供的QuantizeLinear函数对模型进行量化转换，在调用QuantizeLinear函数时，可以指定量化的精度、量化算法和其他相关参数。

当然，在另一可选实施例中，步骤201中，通过CI***对标准模型(如Caffe、ONNX、TFLite下的机器学习模型)进行解析并获取标准化配置信息的具体步骤，也可以实现为如下过程：

首先，选择与不同框架机器学习模型匹配的CI工具，比如Jenkins、Travis CI、GitLab CI等工具中的一个，加载所选的CI工具，以确保CI***连接到版本控制***中，并具备构建和测试功能。进而，根据不同框架机器学习模型，确定所需使用的模型解析方式以及待获取的配置信息类型，并基于模型解析方式以及待获取的配置信息类型生成相应的构建脚本。该构建脚本用于解析标准模型的配置文件，并提取所需的配置信息。在CI工具中设置构建触发器，以便在代码提交或定期时间间隔触发构建过程。这样可以自动运行构建脚本并解析标准模型。进而，在构建脚本中，使用相应的解析工具和库来解析标准模型文件(如caffe.proto、ONNXruntime等)，并提取后续部署过程所需的标准化配置信息。例如，可以获取标准化模型的网络结构、层配置、输入输出张量的维度和类型等信息。最终，CI工具还可以自动运行构建脚本并解析标准化模型，将标准化配置信息输出到指定位置。在验证配置信息是否正确之后，将验证通过的标准化配置信息集成到后续的开发、测试或部署流程中。例如，将解析得到的配置信息输出到CI工具的构建日志、代码仓库中的特定文件或其他适当的位置，以便后续流程能够快速调用这些标准化配置信息。当然，这些存放位置仅为示例，实际应用并不限定。与前文实施例类似，具体的解析方法可以根据标准化模型的属性以及CI工具的支持情况而确定，此处暂不展开介绍。

步骤202，将标准化模型加载到与标准化配置信息匹配的容器镜像中。

在本申请实施例中，容器镜像用于为标准化模型提供转换环境。可以理解的是，容器镜像是一种可执行的软件包，其中包含应用程序的代码、运行时环境、***工具、***库等。可以在任何支持容器化技术的平台上运行，比如Docker、Kubernetes等。使用相同的容器镜像可以在不同环境中运行应用程序，而无需担心环境中的差异性。容器镜像具有以下特点：轻量化，即容器镜像仅包含必要的组件和依赖项，减小了容器镜像的大小，提高了启动和部署的速度；可移植性，即容器镜像在不同环境中运行，不受特定操作***或硬件的限制；一致性，即使用相同的容器镜像可以保证应用程序在不同环境中具有一致的行为；可扩展性，即容器镜像可以进行复制和扩展，以满足不同的需求。

进一步地可选地，容器镜像的创建可以通过Dockerfile文件结合Docker或其他容器化工具进行构建。当容器镜像构建完成之后，可以上传到镜像仓库，以便后续步骤可以调用容器镜像应用到模型部署流程中。

作为一个可选的实施例，步骤202中将标准化模型加载到与标准化配置信息匹配的容器镜像中，可以具体实现为：

根据数据源类型获取标准化模型对应的json数据；构建与json数据匹配的容器镜像，并将标准化模型加载到所构建的容器镜像中。

继续以上文示例的框架为例，数据源类型为Caffe的标准化模型匹配的是Caffe镜像，Caffe镜像中加载有适配于Caffe架构的命令行工具以及接口。数据源类型为TFLite的标准化模型匹配的是TFLite镜像，TFLite镜像中加载有TFLite转换器和TFLite模型解释器。数据源类型为ONNX的标准化模型匹配的是ONNX镜像，ONNX镜像中加载有ONNX Runtime工具，ONNX Runtime工具用于加载测试ONNX模型。

具体而言，根据不同数据源(Caffe、TFLite、ONNX)以及相应的json数据，选择相应的容器镜像，用于承载不同数据源所使用的模型转换工具以及转换环境。下面是分别针对Caffe、TFLite、ONNX这几种数据源的容器镜像选择方法进行示例性介绍：

对于Caffe数据源而言，假设待部署的标准化模型为Caffe模型，那么，就需要在容器镜像中使用Caffe工具进行模型转换和测试，并选择安装Caffe模型所需的镜像环境。具体选择的镜像例如可以是官方提供的Caffe镜像，也可以是第三方维护的Caffe镜像。在Caffe镜像中，可以使用Caffe提供的命令行工具或Python接口来加载和转换Caffe模型，并使用相应的Caffe模型测试工具来展开模型的各种性能测试以及其他相关测试。

对于TFLite数据源而言，假设待部署的标准化模型为TFLite模型，那么，就需要在容器镜像中使用TFLite工具进行模型转换和测试，并选择安装TFLite模型所需的镜像环境。例如，可以采用TensorFlow官方提供的TFLite镜像，该环境中包含TFLite转换器和TFLite模型解释器。在这种镜像环境中，可以使用TFLite转换器将标准化模型转换为目标格式，并使用TFLite模型解释器进行模型测试和推理。

对于ONNX数据源而言，假设待部署的标准化模型为ONNX模型，那么，就需要在容器镜像中使用ONNX工具进行模型转换和测试，并选择安装ONNX Runtime的镜像环境。例如，可以使用ONNX官方提供的ONNX Runtime镜像，该环境中包含ONNX Runtime的Python包和命令行工具。在这种镜像环境中，可以采用ONNX Runtime的工具来加载和测试ONNX模型，从而实现标准化模型的模型转换和推理。

以上仅是示例，具体的镜像选择方法取决于实际的模型转换需求和设备环境要求。

介绍完上述实施例中可选择的容器镜像之后，下面结合具体示例介绍上述实施例中构建与json数据匹配的容器镜像的步骤。作为一种可选实现方式，参见图4，构建与json数据匹配的容器镜像的步骤可以实现为：

步骤401，创建容器镜像的镜像配置文件；

步骤402，基于镜像配置文件构建容器镜像，并在容器镜像中配置模型转换过程所需的转换工具以及环境参数。

其中，镜像配置文件包括数据源类型、转换工具、运行时环境信息、依赖库中的至少一个。转换工具至少包括特定版本的目标驱动程序，环境参数至少包括特定版本的环境配置变量、运行时库。

具体而言，首先，创建Dockerfile。创建一个新的文本文件，命名为Dockerfile。在Dockerfile中，可以先指定基础镜像，例如可以选择基于Ubuntu或适合当前模型转换需求的其他镜像。在Dockerfile中，使用`RUN`命令安装所需的软件包和工具，例如Python、Shell等。可以根据需要指定特定版本，例如RUN apt-get install-y python3＝3.8.10。如果需要设置环境变量，可以使用ENV命令在Dockerfile中指定环境变量。例如ENV PYTHON_PATH＝/usr/bin/python3。

接着，构建Docker镜像。具体地，可以使用docker build命令根据Dockerfile构建Docker镜像。命令的格式为docker build your_image_name:tag.，其中your_image_name是镜像命名的名称，tag是需要为镜像添加的标签，.表示Dockerfile所在的目录。在构建过程中，Docker会执行Dockerfile中的命令，安装所需的软件包和工具，配置环境变量等。构建完成后，可以获得一个新的Docker镜像，其中包含所需的环境和工具。

进而，使用构建完成的Docker镜像。通过运行Docker容器来使用所创建的镜像。可以使用docker run命令来启动容器。在启动容器时，可以使用-v选项将主机的目录挂载到容器中，以便在容器中访问主机上的文件。例如：docker run-v/host/path:/container/path your_image_name:tag。在容器中执行所需的模型转换任务，使用先前配置好的环境变量和工具。

通过这种环境配置方案，可以在容器镜像中加载所需模型转换环境以及转换工具，以便为模型转换过程提供可用环境。此外，Docker还提供了轻量级、可移植和自包含的容器化解决方案，使得模型转换的环境配置更加灵活和方便，避免在非标准平台中可能存在的各种问题。

在前文构建完成模型转换所需的环境之后，为进一步提高模型转换的自动化程度，提升模型转换效率以及在非标平台中的部署效率，可以将转换标准化模型的各个步骤固化为工作流，从而，通过这一工作流将标准化模型自动部署到非标准平台中。当然，还可以采用工作流对某一类型或某几种类型进行模型转换过程的固化，从而使用固化得到的工作流来实现标准化模型的批量部署。

步骤203，根据标准化配置信息，构建用于转换标准化模型的目标工作流。

步骤204，在容器镜像中执行目标工作流，以使标准化模型转换为用于在非标准平台发布的部署模型。

在本申请实施例中，目标工作流至少包括以下流程：模型格式转换、模型量化、模型压缩。目标工作流中的流程参数由非标准平台中搭载的芯片配置决定。

作为一个可选实施例，203中根据标准化配置信息构建用于转换标准化模型的目标工作流的步骤，可以实现为：

首先，创建pipeline项目。比如，在容器镜像中选择构建工具，以创建一个新的pipeline项目。具体创建方式取决于所选工具或平台，通常可以是基于图形界面或命令行来完成。创建之后，还需要为项目命名，并指定所需的配置，例如仓库地址、触发条件等。接着，定义pipeline中的阶段和任务。在pipeline项目中定义各个步骤所需的阶段以及相应任务。将模型转换过程分解为逻辑上独立的任务。例如，阶段a可以是模型量化处理，任务可能包括精度设置、数据格式转换等。针对每个任务配置其对应的执行步骤，例如生成命令行脚本、调用工具或运行特定的程序等，从而确保每个任务能够独立执行。此外，由于模型转换过程需要遵循一定的逻辑顺序，因此，还需确定任务之间的依赖关系，即某些任务必须在其他任务完成之后才能执行，从而确保任务按照正确的顺序执行，并满足其依赖关系。进而，可以根据标准化配置信息来设置pipeline的触发条件和触发器，以明确pipeline的执行启动时机。触发条件可以是定时触发、代码提交触发、手动触发，本申请并不限定。在搭建pipeline流程完成后，还可以进行模型的测试和验证，以确保模型转换任务按照定义的顺序和规则执行，以及确保pipeline可产生预期的模型转换结果。

值得说明的是，还可以进一步配置构建工具或平台以生成任务执行的日志和报告。这样可以方便地查看和分析pipeline的执行结果。当然，还可以配置告警机制，在发生错误或异常时接收通知。例如，通过办公软件通知前台模型转换过程出现异常。

通过以上步骤，可以使用适合模型转换需求的自动化构建工具或平台搭建pipeline流程，实现模型转换的自动化和可控制的执行过程。

本申请实施例中，提供了一种全新的模型转换方式，通过构建用于转换标准化模型的目标工作流，并在容器镜像中执行目标工作流实现标准化模型与非标准***中不同芯片之间的自动化适配处理，降低模型部署难度，提升模型部署效率。

作为一个可选实施例，在步骤204之后，还可以检测是否发生自动部署触发事件。其中，所述自动部署触发事件包括以下至少一种：新增数据集、新增数据模型、模型训练的准确度达到设定阈值、模型训练的损失度降低到设定阈值、达到模型对应的发布周期、模型版本更新、模型时间戳发生预设变化、版本变更条件、数据源发生预设变化。进而，若发生所述自动部署触发事件，则重新在所述容器镜像中执行所述目标工作流，以启动对新获得的标准化模型的转换流程。

可以理解的是，当满足自动部署触发事件时，自动启动标准化模型的转换流程，将新获得的模型转换为可部署的容器镜像，这样可以进一步减少手动部署的工作量，提高了部署的效率和速度。其中，通过监测事件并重新执行转换流程，确保容器镜像中的模型始终是最新版本。当数据集、模型或其他相关条件发生变化时，自动重新执行转换流程，保持模型与最新数据和需求的一致性。通过设置训练准确度、损失度等阈值，只有当模型训练达到预期性能时才触发自动部署，有助于确保部署的模型具有所需的准确度和性能，避免部署低质量的模型。此外，自动部署可以根据需要扩展容器镜像的实例数量，以满足高流量和高负载的需求。当新的模型被部署时，可以实现快速扩展，并在需要时收缩，以提供弹性和高可用性。

本申请实施例中，通过检测自动部署触发事件并重新执行目标工作流，可以实现自动化的模型转换和部署过程，并确保模型始终是最新的、具备期望性能的容器镜像，提高了部署效率、准确度和性能控制，还提供了一种弹性扩展的方式，进一步提升非标准平台的灵活性。

作为一个可选实施例，在步骤204之后，还对转换后的部署模型进行测试验证处理。其中，所述测试验证处理包括模型性能测试和/或精度验证。进而，经过测试验证之后，对部署模型进行推理验证，以验证部署模型在非标准平台中的可用性。

值得说明的是，通过模型的性能测试，可以评估模型在所部署的非标准平台上的速度、内存占用等性能指标，从而有效评估出模型在实际部署环境中的适用性和资源消耗情况，以便根据需求进行调整和优化。而通过精度验证，可以评估模型在非标准平台中的准确度和预测能力。由于模型在不同硬件、操作***或库版本上的性能可能会有所差异，因此此处的精度验证可以有效确保模型在非标准平台中处于较佳的表现，并为模型运行情况提供相对可靠的预测结果。此外，在推理验证阶段中，还可以通过可用性验证来验证部署模型在非标准平台中的可用性。这包括验证模型在实际场景中的预测效果、模型的稳定性和可靠性。通过测试和验证，可以确认模型能够正确地处理输入数据并生成准确的输出。或者，还可以执行错误检测和调试，从而通过测试验证处理可解决检测潜在的错误和问题。通过模型性能测试和精度验证，可以发现潜在的性能瓶颈、错误输出或其他问题，并及时进行调试和修复。

本申请实施例中，对转换后的部署模型进行测试验证处理，有助于评估模型的性能、准确度和可用性，提供了对部署模型在非标准平台上的表现进行全面检查的机会，并帮助确保部署模型的质量和可靠性。

作为一个可选实施例，在步骤204之后，将部署模型信息以通知消息的形式进行输出，以告知模型发布者部署模型已发布到非标准平台中。这样方便用户查看和验证。其中，部署模型信息包括但不限于：模型版本、版本管理说明、发行说明(release note)、关联项目管理说明、测试结果、项目信息、历史版本信息。

不难理解的是，以通知消息的形式输出部署模型信息，能够使用户更为方便地通过浏览器访问和查看模型，无需额外的安装或配置。例如，用户可以通过通知消息界面查看模型的结构、参数和其他相关信息，以及进行模型的测试和验证。通过以通知消息形式输出部署模型信息，以直观的方式理解模型的特性和性能，提升了模型部署过程的交互性和可视化展示。而通过通知消息，用户可以及时收到部署模型的发布情况和相关状态。这也可以帮助用户及时了解模型在非标准平台上的部署情况，并及时进行调整和处理。通过通知消息还使得用户可以及时获得部署模型的发布通知，无需手动检查和确认，提高了模型发布的效率，使用户能够更快地将模型推送到非标准平台中进行使用。当然，这种方式还确保了数据的透明度，非发布者的授权用户可以通过通知消息界面了解模型的详细信息，而模型发布者可以通过消息通知跟踪和监控部署过程。

本申请实施例中，将部署模型信息以通知消息形式输出，有助于提供方便的用户体验、快速的发布通知、可视化和透明的展示方式，从而提高模型的使用和发布效率。

除此之外，上述实施例中介绍的各个模型转换步骤均可通过飞书或其他通知消息的形式呈现给用户，以便于用户通过可视化的模型转换进度信息来监控模型转换过程，及时发现模型转换过程中可能出现的异常，提高模型的使用和发布效率。

在介绍了本申请实施例的方法之后，接下来，参考图5对本申请实施例的模型转换装置进行介绍。

本申请实施例中的模型转换装置50能够实现对应于上述图2所对应的实施例中模型转换方法的步骤。模型转换装置50实现的功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块，所述模块可以是软件和/或硬件。模型转换装置50可包括解析模块501、加载模块502、构建模块503、执行模块504，这几个模块的功能实现可参考图2所对应的实施例中所执行的操作，此处不作赘述。

一些实施方式中，解析模块501，被配置为通过CI***解析待处理的标准化模型，以得到所述标准化模型的标准化配置信息；

加载模块502，被配置为将所述标准化模型加载到与所述标准化配置信息匹配的容器镜像中；其中，所述容器镜像用于为所述标准化模型提供转换环境；

构建模块503，被配置为根据所述标准化配置信息，构建用于转换所述标准化模型的目标工作流；所述目标工作流至少包括以下流程：模型格式转换、模型量化、模型压缩；所述目标工作流中的流程参数由非标准平台中搭载的芯片配置决定；

执行模块504，被配置为在所述容器镜像中执行所述目标工作流，以使所述标准化模型转换为用于在非标准平台发布的部署模型。

一些实施方式中，所述解析模块501，通过CI***解析待处理的标准化模型，以得到所述标准化模型的标准化配置信息时，被配置为：

根据所述标准化模型所属的数据源类型，选择与所述数据源类型匹配的目标解析器；所述数据源类型为Caffe、TFLite、ONNX中的一种；

将所述标准化模型的模型文件加载到所述目标解析器中；

通过所述目标解析器提取所述标准化模型的模型结构和/或参数配置信息；

其中，所述模型结构至少包括以下中的一种：模型结构类型、模型层次、参数量；所述参数配置信息至少包括以下中的一种：量化算法、量化精度、目标格式。

一些实施方式中，所述加载模块502，将所述标准化模型加载到与所述标准化配置信息匹配的容器镜像中时，被配置为：

根据所述数据源类型获取所述标准化模型对应的json数据；

构建与json数据匹配的容器镜像，并将所述标准化模型加载到所构建的容器镜像中；

其中，所述数据源类型为Caffe的标准化模型匹配的是Caffe镜像，所述Caffe镜像中加载有适配于Caffe架构的命令行工具以及接口；所述数据源类型为TFLite的标准化模型匹配的是TFLite镜像，所述TFLite镜像中加载有TFLite转换器和TFLite模型解释器；所述数据源类型为ONNX的标准化模型匹配的是ONNX镜像，所述ONNX镜像中加载有ONNXRuntime工具，所述ONNX Runtime工具用于加载测试ONNX模型。

一些实施方式中，所述加载模块502，构建与json数据匹配的容器镜像时，被配置为：

创建容器镜像的镜像配置文件；所述镜像配置文件包括数据源类型、转换工具、运行时环境信息、依赖库中的至少一个；

基于所述镜像配置文件构建所述容器镜像，并在所述容器镜像中配置模型转换过程所需的转换工具以及环境参数；

所述转换工具至少包括特定版本的目标驱动程序，所述环境参数至少包括特定版本的环境配置变量、运行时库。

一些实施方式中，所述装置还包括检测模块，还被配置为：

在执行模块504在所述容器镜像中执行所述目标工作流，以使所述标准化模型转换为用于在非标准平台发布的部署模型之后，检测是否发生自动部署触发事件；所述自动部署触发事件包括以下至少一种：新增数据集、新增数据模型、模型训练的准确度达到设定阈值、模型训练的损失度降低到设定阈值、达到模型对应的发布周期、模型版本更新、模型时间戳发生预设变化、版本变更条件、数据源发生预设变化；若发生所述自动部署触发事件，则重新在所述容器镜像中执行所述目标工作流，以启动对新获得的标准化模型的转换流程。

一些实施方式中，所述装置还包括检测模块，还被配置为：

在执行模块504在所述容器镜像中执行所述目标工作流，以使所述标准化模型转换为用于在非标准平台发布的部署模型之后，对转换后的部署模型进行测试验证处理；所述测试验证处理包括模型性能测试和/或精度验证；经过测试验证之后，对部署模型进行推理验证，以验证部署模型在非标准平台中的可用性。

一些实施方式中，所述装置还包括检测模块，还被配置为：

在执行模块504在所述容器镜像中执行所述目标工作流，以使所述标准化模型转换为用于在非标准平台发布的部署模型之后，将部署模型信息以通知消息形式进行输出，以告知模型发布者所述部署模型已发布到非标准平台中。

本申请实施例中，模型转换装置可以通过构建用于转换标准化模型的目标工作流，并在容器镜像中执行目标工作流实现标准化模型与非标准***中不同芯片之间的自动化适配处理，降低模型部署难度，提升模型部署效率。

在介绍了本申请实施例的方法和装置之后，接下来，对本申请实施例的计算机可读存储介质进行说明，计算机可读存储介质可为光盘，其上存储有计算机程序(即程序产品)，所述计算机程序在被处理器运行时，会实现上述方法实施方式中所记载的各步骤，例如，通过持续集成***解析待处理的标准化模型，以得到标准化模型的标准化配置信息；将标准化模型加载到与标准化配置信息匹配的容器镜像中；容器镜像用于为标准化模型提供转换环境；根据标准化配置信息，构建用于转换标准化模型的目标工作流；目标工作流至少包括以下流程：模型格式转换、模型量化、模型压缩；目标工作流中的流程参数由非标准平台中搭载的芯片配置决定；在容器镜像中执行目标工作流，以使标准化模型转换为用于在非标准平台发布的部署模型。各步骤的具体实现方式在此不再重复说明。

需要说明的是，所述计算机可读存储介质的例子还可以包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他光学、磁性存储介质，在此不再一一赘述。

上面从模块化功能实体的角度对本申请实施例中的模型转换装置50进行了描述，下面从硬件处理的角度分别对本申请实施例中的执行模型转换方法的服务器、终端设备进行描述。

需要说明的是，本申请模型转换装置实施例还可以包括收发模块，该收发模块用于数据传输，该收发模块对应的实体设备可以为输入/输出单元、收发器、射频电路、通信模块和输入/输出(I/O)接口等，解析模块、加载模块、构建模块、执行模块这些模块对应的实体设备可以为处理器。图5所示的模型转换装置50可以具有如图6所示的结构，当图5所示的模型转换装置50具有如图6所示的结构时，图6中的处理器和收发器能够实现前述对应该装置的装置实施例提供的模块相同或相似的功能，图6中的存储器存储处理器执行上述模型转换方法时需要调用的计算机程序。

图7是本申请实施例提供的一种服务器结构示意图，该服务器1100可因配置或性能不同而产生比较大的差异，可以包括一个或一个以***处理器(central processingunits，CPU)1122(例如，一个或一个以上处理器)和存储器1132，一个或一个以上存储应用程序1142或数据1144的存储介质1130(例如一个或一个以上海量存储设备)。其中，存储器1132和存储介质1130可以是短暂存储或持久存储。存储在存储介质1130的程序可以包括一个或一个以上模块(图中未示出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1122可以设置为与存储介质1130通信，在服务器1100上执行存储介质1130中的一系列指令操作。

服务器1100还可以包括一个或一个以上电源1126，一个或一个以上有线或无线网络接口1150，一个或一个以上输入输出接口1158，和/或，一个或一个以上操作***1141，例如Windows Server，Mac OS X，Unix，Linux，FreeBSD等等。

上述实施例中由服务器所执行的步骤可以基于该图7所示的服务器1100的结构。例如，例如上述实施例中由图7所示的模型转换装置60所执行的步骤可以基于该图7所示的服务器结构。例如，所述中央处理器1122通过调用存储器1132中的指令，执行以下操作：

通过输入输出接口1158通过持续集成***解析待处理的标准化模型，以得到标准化模型的标准化配置信息；将标准化模型加载到与标准化配置信息匹配的容器镜像中；容器镜像用于为标准化模型提供转换环境；根据标准化配置信息，构建用于转换标准化模型的目标工作流；目标工作流至少包括以下流程：模型格式转换、模型量化、模型压缩；目标工作流中的流程参数由非标准平台中搭载的芯片配置决定；在容器镜像中执行目标工作流，以使标准化模型转换为用于在非标准平台发布的部署模型。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***，装置和模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请实施例所提供的几个实施例中，应该理解到，所揭露的***，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本申请实施例各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机计算机程序时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

以上对本申请实施例所提供的技术方案进行了详细介绍，本申请实施例中应用了具体个例对本申请实施例的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请实施例的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请实施例的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请实施例的限制。

Claims (10)

1.一种模型转换方法，其特征在于，所述方法包括：

通过持续集成CI***解析待处理的标准化模型，以得到所述标准化模型的标准化配置信息；

将所述标准化模型加载到与所述标准化配置信息匹配的容器镜像中；其中，所述容器镜像用于为所述标准化模型提供转换环境；

根据所述标准化配置信息，构建用于转换所述标准化模型的目标工作流；所述目标工作流至少包括以下流程：模型格式转换、模型量化、模型压缩；所述目标工作流中的流程参数由非标准平台中搭载的芯片配置决定；

在所述容器镜像中执行所述目标工作流，以使所述标准化模型转换为用于在非标准平台发布的部署模型。

2.如权利要求1所述的方法，其特征在于，所述通过CI***解析待处理的标准化模型，以得到所述标准化模型的标准化配置信息，包括：

根据所述标准化模型所属的数据源类型，选择与所述数据源类型匹配的目标解析器；所述数据源类型为Caffe、TFLite、ONNX中的一种；

将所述标准化模型的模型文件加载到所述目标解析器中；

通过所述目标解析器提取所述标准化模型的模型结构和/或参数配置信息；

其中，所述模型结构至少包括以下中的一种：模型结构类型、模型层次、参数量；所述参数配置信息至少包括以下中的一种：量化算法、量化精度、目标格式。

3.如权利要求2所述的方法，其特征在于，所述将所述标准化模型加载到与所述标准化配置信息匹配的容器镜像中，包括：

根据所述数据源类型获取所述标准化模型对应的json数据；

构建与json数据匹配的容器镜像，并将所述标准化模型加载到所构建的容器镜像中；

其中，所述数据源类型为Caffe的标准化模型匹配的是Caffe镜像，所述Caffe镜像中加载有适配于Caffe架构的命令行工具以及接口；所述数据源类型为TFLite的标准化模型匹配的是TFLite镜像，所述TFLite镜像中加载有TFLite转换器和TFLite模型解释器；所述数据源类型为ONNX的标准化模型匹配的是ONNX镜像，所述ONNX镜像中加载有ONNX Runtime工具，所述ONNX Runtime工具用于加载测试ONNX模型。

4.如权利要求3所述的方法，其特征在于，所述构建与json数据匹配的容器镜像，包括：

创建容器镜像的镜像配置文件；所述镜像配置文件包括数据源类型、转换工具、运行时环境信息、依赖库中的至少一个；

基于所述镜像配置文件构建所述容器镜像，并在所述容器镜像中配置模型转换过程所需的转换工具以及环境参数；

所述转换工具至少包括特定版本的目标驱动程序，所述环境参数至少包括特定版本的环境配置变量、运行时库。

5.如权利要求1所述的方法，其特征在于，所述在所述容器镜像中执行所述目标工作流，以使所述标准化模型转换为用于在非标准平台发布的部署模型之后，还包括：

检测是否发生自动部署触发事件；所述自动部署触发事件包括以下至少一种：新增数据集、新增数据模型、模型训练的准确度达到设定阈值、模型训练的损失度降低到设定阈值、达到模型对应的发布周期、模型版本更新、模型时间戳发生预设变化、版本变更条件、数据源发生预设变化；

若发生所述自动部署触发事件，则重新在所述容器镜像中执行所述目标工作流，以启动对新获得的标准化模型的转换流程。

6.如权利要求1所述的方法，其特征在于，所述在所述容器镜像中执行所述目标工作流，以使所述标准化模型转换为用于在非标准平台发布的部署模型之后，还包括：

对转换后的部署模型进行测试验证处理；所述测试验证处理包括模型性能测试和/或精度验证；

经过测试验证之后，对部署模型进行推理验证，以验证部署模型在非标准平台中的可用性。

7.如权利要求1所述的方法，其特征在于，所述在所述容器镜像中执行所述目标工作流，以使所述标准化模型转换为用于在非标准平台发布的部署模型之后，还包括：

将部署模型信息以通知消息的形式进行输出，以告知模型发布者所述部署模型已发布到非标准平台中。

8.一种模型转换装置，其特征在于，所述装置包括：

解析模块，被配置为通过CI***解析待处理的标准化模型，以得到所述标准化模型的标准化配置信息；

加载模块，被配置为将所述标准化模型加载到与所述标准化配置信息匹配的容器镜像中；其中，所述容器镜像用于为所述标准化模型提供转换环境；

构建模块，被配置为根据所述标准化配置信息，构建用于转换所述标准化模型的目标工作流；所述目标工作流至少包括以下流程：模型格式转换、模型量化、模型压缩；所述目标工作流中的流程参数由非标准平台中搭载的芯片配置决定；

执行模块，被配置为在所述容器镜像中执行所述目标工作流，以使所述标准化模型转换为用于在非标准平台发布的部署模型。

9.一种计算设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现权利要求1-7中任一项所述的方法。

10.一种计算机可读存储介质，其包括指令，当其在计算机上运行时，使得计算机执行如权利要求1-7中任一项所述的方法。