CN110532098B - 提供gpu服务的方法及系统 - Google Patents

Abstract

本公开涉及深度学习服务的技术领域，公开了一种提供GPU服务的方法及系统，方法包括以下步骤：在容器集群管理系统中启动容器；读取配置信息并根据所述配置信息加载容器中的推理服务端；接收客户端的请求信息，根据所述请求信息向所述推理服务端发送计算指令，所述计算指令用于指示所述推理服务端调用基于Caffe框架部署的模型在GPU上进行推理；接收所述推理服务端返回的计算结果；将所述计算结果发送给所述客户端。本公开的一些技术效果在于：通过在容器中加载推理服务端，调用Caffe框架部署的模型在GPU上进行推理，能以较高的效率满足客户端的服务请求。

Description

提供GPU服务的方法及系统

技术领域

本公开涉及深度学习服务的技术领域，特别涉及提供GPU服务的方法及系统。

背景技术

深度学习(DL，Deep Learning)近年来发展极其迅猛，基于卷积神经网络(CNNs，Convolutional Neural Networks)的各项研究进行得如火如荼，学术文献层出不穷。而这些研究成果的涌现离不开硬件的支持，正是图像处理单元(GPU，Graphics ProcessingUnit)的超强计算能力给予了浅层神经网络飞速发展成深层神经网络的可能。因此GPU是深度学习研究和应用不可或缺的计算资源。

深度学习的应用领域极其广泛，例如图像处理、语音识别、目标检测等领域均有涉及。这些应用的流程通常包括三个步骤：

(1)收集相应数据(如图像、语音等)进行标注等预处理操作；

(2)以上述经过预处理的数据进行深度模型的训练；

(3)用训练完成的模型进行推理(inference)。

上述第(1)、(2)步相当于程序的开发阶段，第(3)步才是最终的实施阶段。在实施阶段，通常是将训练完成的模型部署到生产环境进行使用。

作为深度学习开发工具之一，Caffe与其他深度学习开发工具相比，主要有以下两个区别：

(1)Caffe完全用C++语言来实现，便于移植，并且无硬件和平台的限制，适用于商业开发和科学研究；

(2)Caffe提供了许多训练好的模型，通过微调(Fine-Tuning)这些模型，在不用重写大量代码的情况下，就可以快速、高效的开发出新的应用，这也是当下软件应用开发的趋势。

在地图生产业务中，部分环节(如图像分割、目标检测等)可以借助Caffe框架进行实施，能提高总体效率以及简化生产流程。但当前还没有为Caffe框架提供较好的模型部署服务的方法或系统。

TensorFlow Serving是为生产环境设计的一种机器学习模型服务系统，可用于部署模型提供调用服务。但是TensorFlow Serving并不提供对深度学习框架Caffe的支持。

Caffe模型的部署的实质可以理解为是GPU服务的部署，TensorFlow Serving中为了提高GPU资源的利用率，利用Batcher将多个推理请求组合成一个批处理请求，这种模式对于Caffe则不适用，Caffe框架下的模型虽然也可以一次加载多条数据进行处理，但是其内部的代码逻辑依然是顺序执行而非并行，如果采用批次模式，则不仅占用更多的显存资源，而且处理速度得不到提升，因此需要另外考虑Caffe模型的部署方式。

发明内容

为解决前述的至少一个技术问题，本公开在一个方面提出了一种提供GPU服务的方法，包括以下步骤：在容器集群管理系统中启动容器；读取配置信息并根据所述配置信息加载容器中的推理服务端；接收客户端的请求信息，根据所述请求信息向所述推理服务端发送计算指令，所述计算指令用于指示所述推理服务端调用基于Caffe框架部署的模型在GPU上进行推理；接收所述推理服务端返回的计算结果；将所述计算结果发送给所述客户端。

优选地，所述容器集群管理系统为Kubernetes，所述容器为Docker容器；通过Service的开放端口接收所述请求信息以及发出所述计算结果。

优选地，还包括以下步骤：所述请求信息包括请求调用的函数信息；接收所述请求信息后，判断所述推理服务端是否存在所述请求调用的函数；若存在，则向所述推理服务端发送所述计算指令；若不存在，则向所述客户端返回错误信息。

优选地，“加载容器中的推理服务端”包括以下步骤：获取显存信息，并据此配置线程数量，所述配置信息包括所述线程数量；将供所述客户端调用的函数绑定到所述推理服务端；根据所述请求信息以及所述线程数量，选择对应类型以及数量的模型进行初始化，所述初始化的模型的数量与所述线程数量保持一致。

优选地，生成状态描述列表，所述状态描述列表用于记录容器中加载的每一份模型文件与状态描述符的对应关系；不同类型的所述状态描述符分别用于表征的状态至少包括第一状态、第二状态以及第三状态；所述第一状态示意所述模型文件处于空闲的状态；所述第二状态示意所述模型文件处于被调用进行推理的状态；所述第三状态示意所述模型文件处于更新中的状态；响应于检测指令，对存放所述模型文件的目录进行检测，判断所述目录内的文件是否发生变化，若是，则持续将所有表征第一状态的状态描述符修改为表征第三状态的状态描述符；循环搜索所述状态描述列表，判断是否存在表征第二状态的状态描述符，直至不存在时，停止所述循环搜索，释放容器中变化前的模型文件，并从所述目录加载变化后的模型文件，然后进行初始化；初始化完成后，将状态描述列表中所有表征第三状态的状态描述符修改为表征第一状态的状态描述符。

优选地，所述请求信息包括待处理的图像数据；当请求调用的函数信息包括单帧分割函数信息时，响应于所述计算指令，所述推理服务端执行以下操作：接收所述图像数据作为参数；对待处理图像数据进行预处理操作；选择处于第一状态的、用于进行单帧分割的模型，并将其状态描述符修改为表征第二状态的状态描述符；调用该模型对预处理后的图像数据进行推理，获得推理数据；将该模型的状态描述符修改为表征第一状态的状态描述符，并对所述推理数据进行后处理，得到所述计算结果。

优选地，所述请求信息包括待处理的图像数据；当请求调用的函数信息包括单帧检测函数信息时，响应于所述计算指令，所述推理服务端执行以下操作：接收所述图像数据作为参数；对待处理图像数据进行预处理操作；选择处于第一状态的、用于进行单帧检测的模型，并将其状态描述符修改为表征第二状态的状态描述符；调用该模型对预处理后的图像数据进行推理，获得推理数据；将该模型的状态描述符修改为表征第一状态的状态描述符，并对所述推理数据进行后处理，得到所述计算结果。

优选地，所述请求信息包括待处理的视频数据；当请求调用的函数信息包括视频分割函数信息时，响应于所述计算指令，所述推理服务端执行以下操作：根据所述待处理的视频数据获得视频路径；根据所述视频路径将待处理的视频信息拉取到本地；读取所述视频信息，依次对视频帧进行预处理操作；选取处于第一状态的、用于进行视频分割的模型，并其状态描述符修改为表征第二状态的状态描述符；调用该模型对预处理后的视频帧进行推理，获得推理数据；对所有视频帧的推理数据进行后处理，写入结果视频文件；将该模型的状态描述符修改为表征第一状态的状态描述符；删除本地视频文件，并上传所述结果视频文件，获得结果视频路径作为所述计算结果。

优选地，所述请求信息包括待处理的视频数据；当请求调用的函数信息包括视频检测函数信息时，响应于所述计算指令，所述推理服务端执行以下操作：根据所述待处理的视频数据获得视频路径；根据所述视频路径将待处理的视频信息拉取到本地；读取所述视频信息，依次对视频帧进行预处理操作；选取处于第一状态的、用于进行视频检测的模型，并其状态描述符修改为表征第二状态的状态描述符；调用该模型对预处理后的视频帧进行推理，获得推理数据；对所有视频帧的推理数据进行后处理，写入TXT结果文件；将该模型的状态描述符修改为表征第一状态的状态描述符；删除本地视频文件，并上传所述TXT结果文件，获得TXT结果文件路径作为所述计算结果。

在一个方面，本公开还提出了一种提供GPU服务的系统，包括以下模块：容器管理模块，用于在容器集群管理系统中启动容器；服务端加载模块，用于读取配置信息并根据所述配置信息加载容器中的推理服务端；服务对接模块，用于执行以下步骤：接收客户端的请求信息，根据所述请求信息向所述推理服务端发送计算指令，所述计算指令用于指示所述推理服务端调用基于Caffe框架部署的模型在GPU上进行推理；接收所述推理服务端返回的计算结果；将所述计算结果发送给所述客户端。

本公开的一些技术效果在于：通过在容器中加载推理服务端，调用Caffe框架部署的模型在GPU上进行推理，能以较高的效率满足客户端的服务请求。

附图说明

为更好地理解本公开的技术方案，可参考下列的、用于对现有技术或实施例进行辅助说明的附图。这些附图将对现有技术或本公开部分实施例中，涉及到的产品或方法有选择地进行展示。这些附图的基本信息如下：

图1为一个实施例中，本公开所述技术方案的一种系统架构示意图。

具体实施方式

下文将对本公开涉及的技术手段或技术效果作进一步的展开描述，显然，所提供的实施例(或实施方式)仅是本公开意旨涵盖的部分实施方式，而并非全部。基于本公开中的实施例以及图文的明示或暗示，本领域技术人员在没有作出创造性劳动的前提下所能获得的所有其他实施例，都将在本公开保护的范围之内。

总体思路上，本公开提出一种提供GPU服务的方法，包括以下步骤：在容器集群管理系统中启动容器；读取配置信息并根据所述配置信息加载容器中的推理服务端；接收客户端的请求信息，根据所述请求信息向所述推理服务端发送计算指令，所述计算指令用于指示所述推理服务端调用基于Caffe框架部署的模型在GPU上进行推理；接收所述推理服务端返回的计算结果；将所述计算结果发送给所述客户端。

本公开的一些技术效果在于：通过在容器中加载推理服务端，调用Caffe框架部署的模型在GPU上进行推理，能以较高的效率满足客户端的服务请求。

关于容器(Container)。一般来说，我们对物理资源进行管理，需要进行虚拟化。即在一台物理服务器上，运行多台虚拟服务器。这种虚拟服务器，也叫虚拟机(VM，VirtualMachine)。从表面来看，这些虚拟机都是独立的服务器，但实际上，它们共享物理服务器的CPU、内存、硬件、网卡等资源。如此，除了少部分特殊类型的应用，大部分的业务应用可以在虚拟机(或云主机)上面运行。但当下所有的虚拟机技术方案，都存在一些缺陷：例如虚拟机是一个独立的操作系统，对于一些小进程或者一些较轻的业务应用而言，为其分别建立虚拟机会导致资源的浪费以及配置管理效率的低下。在一些情况下，迁移服务程序必须迁移整个虚拟机，在效能上也是不够合理的。相比于虚拟机，容器具有更多开发者所需要的优势：所有业务应用可以直接运行在物理主机的操作系统之上，可以直接读写磁盘，应用之间通过计算、存储和网络资源的命名空间进行隔离，为每个应用形成一个逻辑上独立的“容器操作系统”；同时容器技术还有以下优点：简化部署、多环境支持、快速启动、服务编排、易于迁移。

综上，容器也是虚拟化，但是属于“轻量级”的虚拟化。它的目的和虚拟机一样，都是为了创造“隔离环境”；虚拟机是操作系统级别的资源隔离，而容器本质上是进程级的资源隔离。

目前，主流的容器集群管理系统包括Kubernetes、Docker Swarm及MesosphereMarathon等。容器集群管理系统主要职责是容器编排(Container Orchestration)，例如启动容器、自动化部署、扩展和管理容器应用、回收容器等。

在一个实施例中，所述容器集群管理系统为Kubernetes，所述容器为Docker容器；通过Service的开放端口接收所述请求信息以及发出所述计算结果。该实施例中，GPU集群是基于Kubernetes部署的，Kubernetes是自动化容器操作的开源平台，这些操作包括部署、调度和节点集群间扩展。如图1所示，Kubernetes的Service用于对外开放GPU服务；Service连接着后端的多个Container(即容器，一些实施例中，容器为docker容器)，Container中包含了基于Caffe框架部署的推理服务端。

我方将GPU服务设计为Kubernetes中的Service，客户端可通过Service的开放端口访问后端多个docker容器，这些容器具有相同的资源配置和程序(即推理服务端的程序)。

Kubernetes本身具有负载均衡机制，客户端不会集中访问某一个后端，在一定程度上保证了服务的稳定性。同时，Kubernetes具有的自我修复特性会在检测到某个容器出现故障时完成容器的重启步骤，而横向缩放特性会根据设置的线程数量维持后端容器的数量。

在一个实施例中，所述请求信息包括请求调用的函数信息；接收所述请求信息后，判断所述推理服务端是否存在所述请求调用的函数；若存在，则向所述推理服务端发送所述计算指令；若不存在，则向所述客户端返回错误信息。

本公开提出的提供GPU服务的方法，本质上是为客户端提供远程的计算服务，该计算服务是根据客户端的请求而启动的。在一些具体的应用领域，如地图制作(也称地图生产)领域，客户端可以向服务器发出图片或视频的处理请求(如单帧分割、单帧检测、视频分割以及视频检测的请求)，服务器据此通过函数模块调用相应的模型进行运算，提供相关的GPU服务。更具体地，在一个实施例中，提供GPU服务可以基于现有的RPC框架和MessagePack序列化格式实现。RPC是一种请求——响应模型，即客户端发起请求，服务器返回响应，像调用本地函数一样地调用远程函数。为了在网络上传输和接收数据，需要对数据进行序列化和反序列化，相比TensorFlow Serving所应用的Protobuf格式，本公开采用MessagePack作为序列化协议，无需编写描述映射文件(如Protobuf的.proto文件)直接序列化类对象。

本文所说的模型，指的是深度学习模型。

在一个实施例中，“加载容器中的推理服务端”包括以下步骤：获取显存信息，并据此配置线程数量，所述配置信息包括所述线程数量；将供所述客户端调用的函数绑定到所述推理服务端；根据所述请求信息以及所述线程数量，选择对应类型以及数量的模型进行初始化，所述初始化的模型的数量与所述线程数量保持一致。根据显存情况和需求指定初始化模型的总数量，由于Caffe与TenforFlow等框架不同，无法利用批处理提高处理效率，因此需要通过多线程运行模型来提高显存的利用率，初始化模型的总数量应与推理服务端设置的线程数量一致。

在一个实施例中，“加载容器中的推理服务端”还可以包括设置端口号，对端口号进行监听，当接收到所述请求信息时，进行模型的初始化。

在一个实施例中，对多个模型进行初始化，当这些模型具有不同类型时，例如这些模型包括了分割模型以及检测模型，可以将这些经过初始化的模型对象分别放入分割模型列表和检测模型列表，这两个列表分别各自对应一个状态描述列表，状态描述列表中每个元素与模型列表中的模型对象一一关联，也就是说每一个模型对象对应着一个状态描述符，状态描述符用来表述模型的当前状态，状态可以包括更新中、调用中、空闲等。本领域技术人员还可以根据模型具有的其他类型，进行相适应地调整实施方案。

为了更好地解决模型更新的问题，在一个实施例中，生成状态描述列表，所述状态描述列表用于记录容器中加载的每一份模型文件与状态描述符的对应关系；不同类型的所述状态描述符分别用于表征的状态至少包括第一状态、第二状态以及第三状态；所述第一状态示意所述模型文件处于空闲的状态；所述第二状态示意所述模型文件处于被调用进行推理的状态；所述第三状态示意所述模型文件处于更新中的状态；响应于检测指令，对存放所述模型文件的目录进行检测，判断所述目录内的文件是否发生变化，若是，则持续将所有表征第一状态的状态描述符修改为表征第三状态的状态描述符；循环搜索所述状态描述列表，判断是否存在表征第二状态的状态描述符，直至不存在时，停止所述循环搜索，释放容器中变化前的模型文件，并从所述目录加载变化后的模型文件，然后进行初始化；初始化完成后，将状态描述列表中所有表征第三状态的状态描述符修改为表征第一状态的状态描述符。所述检测指令既可以是定期自动发出的，也可以是由管理人员手工操作而发出的，主要用于指示对存放模型文件的目录内容进行校验操作。

在一个实施例中，所述请求信息包括待处理的图像数据；当请求调用的函数信息包括单帧分割函数信息时，响应于所述计算指令，所述推理服务端执行以下操作：接收所述图像数据作为参数；对待处理图像数据进行预处理操作；选择处于第一状态的、用于进行单帧分割的模型，并将其状态描述符修改为表征第二状态的状态描述符；调用该模型对预处理后的图像数据进行推理，获得推理数据；将该模型的状态描述符修改为表征第一状态的状态描述符，并对所述推理数据进行后处理，得到所述计算结果。

在一个实施例中，所述请求信息包括待处理的图像数据；当请求调用的函数信息包括单帧检测函数信息时，响应于所述计算指令，所述推理服务端执行以下操作：接收所述图像数据作为参数；对待处理图像数据进行预处理操作；选择处于第一状态的、用于进行单帧检测的模型，并将其状态描述符修改为表征第二状态的状态描述符；调用该模型对预处理后的图像数据进行推理，获得推理数据；将该模型的状态描述符修改为表征第一状态的状态描述符，并对所述推理数据进行后处理，得到所述计算结果。

在一个实施例中，所述请求信息包括待处理的视频数据；当请求调用的函数信息包括视频分割函数信息时，响应于所述计算指令，所述推理服务端执行以下操作：根据所述待处理的视频数据获得视频路径；根据所述视频路径将待处理的视频信息拉取到本地；读取所述视频信息，依次对视频帧进行预处理操作；选取处于第一状态的、用于进行视频分割的模型，并其状态描述符修改为表征第二状态的状态描述符；调用该模型对预处理后的视频帧进行推理，获得推理数据；对所有视频帧的推理数据进行后处理，写入结果视频文件；将该模型的状态描述符修改为表征第一状态的状态描述符；删除本地视频文件，并上传所述结果视频文件，获得结果视频路径作为所述计算结果。

在一个实施例中，所述请求信息包括待处理的视频数据；当请求调用的函数信息包括视频检测函数信息时，响应于所述计算指令，所述推理服务端执行以下操作：根据所述待处理的视频数据获得视频路径；根据所述视频路径将待处理的视频信息拉取到本地；读取所述视频信息，依次对视频帧进行预处理操作；选取处于第一状态的、用于进行视频检测的模型，并其状态描述符修改为表征第二状态的状态描述符；调用该模型对预处理后的视频帧进行推理，获得推理数据；对所有视频帧的推理数据进行后处理，写入TXT结果文件；将该模型的状态描述符修改为表征第一状态的状态描述符；删除本地视频文件，并上传所述TXT结果文件，获得TXT结果文件路径作为所述计算结果。

前述的四种函数，单帧分割函数、单帧检测函数、视频分割函数、视频检测函数，仅是部分的GPU服务涉及的函数，本领域技术人员可根据知晓的知识进行设计，采用更多的功能函数。前述的四种函数涉及的服务分别是单帧分割、单帧检测、视频分割、视频检测，是地图制作或图像处理技术领域常见的服务，其涉及的代码可以采用现成的、开源的。其中，单帧分割的目的是对图像数据进行分割处理，图像分割即是将图像的每个像素进行分类，输出的分割结果图中的每个像素为类别索引值；类似地，视频可以看做是由一帧帧图像组成，视频分割一般是指对视频帧逐一进行分割，输出的一般是视频格式的文件。单帧检测一般指的是对图像数据中的特定类别元素进行识别，判断图片中是否存在某种元素并获取其在图像中的位置信息，或者判断图片中存在哪些类型的元素，输出的一般是这些元素的类型信息和位置信息；类似地，视频检测也可以输出这些元素的类型信息和位置信息。

在一个方面，本公开还提出了一种提供GPU服务的系统，包括以下模块：容器管理模块，用于在容器集群管理系统中启动容器；服务端加载模块，用于读取配置信息并根据所述配置信息加载容器中的推理服务端；服务对接模块，用于执行以下步骤：接收客户端的请求信息，根据所述请求信息向所述推理服务端发送计算指令，所述计算指令用于指示所述推理服务端调用基于Caffe框架部署的模型在GPU上进行推理；接收所述推理服务端返回的计算结果；将所述计算结果发送给所述客户端。

本领域技术人员可以理解的是，实施例中的全部或部分步骤，可以通过计算机程序来指令相关的硬件实现，该程序可以存储于计算机可读介质中，可读介质可以包括闪存盘、移动硬盘、只读存储器、随机存取器、磁盘或光盘等各种可以存储程序代码的介质。

在符合本领域技术人员的知识和能力水平范围内，本文提及的各种实施例或者技术特征在不冲突的情况下，可以相互组合而作为另外一些可选实施例，这些并未被一一罗列出来的、由有限数量的技术特征组合形成的有限数量的可选实施例，仍属于本公开揭露的技术范围内，亦是本领域技术人员结合附图和上文所能理解或推断而得出的。

另外，多数实施例的描述是基于不同的重点而展开的，未详述之处，可参见现有技术的内容或本文的其他相关描述进行理解。

再次强调，上文所列举的实施例，为本公开较为典型的、较佳实施例，仅用于详细说明、解释本公开的技术方案，以便于读者理解，并不用以限制本公开的保护范围或者应用。在本公开的精神和原则之内所作的任何修改、等同替换、改进等而获得的技术方案，都应被涵盖在本公开的保护范围之内。

Claims (7)

1.提供GPU服务的方法，其特征在于，包括以下步骤：

在容器集群管理系统中启动容器；

读取配置信息并根据所述配置信息加载容器中的推理服务端；

接收客户端的请求信息，根据所述请求信息向所述推理服务端发送计算指令，所述计算指令用于指示所述推理服务端调用基于Caffe框架部署的模型在GPU上进行推理；

所述请求信息包括请求调用的函数信息；接收所述请求信息后，判断所述推理服务端是否存在所述请求调用的函数；若存在，则向所述推理服务端发送所述计算指令；若不存在，则向所述客户端返回错误信息；

所述“加载容器中的推理服务端”包括以下步骤：获取显存信息，并据此配置线程数量，所述配置信息包括所述线程数量；将供所述客户端调用的函数绑定到所述推理服务端；根据所述请求信息以及所述线程数量，选择对应类型以及数量的模型进行初始化，所述初始化的模型的数量与所述线程数量保持一致；

生成状态描述列表，所述状态描述列表用于记录容器中加载的每一份模型文件与状态描述符的对应关系；不同类型的所述状态描述符分别用于表征的状态至少包括第一状态、第二状态以及第三状态；所述第一状态示意所述模型文件处于空闲的状态；所述第二状态示意所述模型文件处于被调用进行推理的状态；所述第三状态示意所述模型文件处于更新中的状态；响应于检测指令，对存放所述模型文件的目录进行检测，判断所述目录内的文件是否发生变化，若是，则持续将所有表征第一状态的状态描述符修改为表征第三状态的状态描述符；循环搜索所述状态描述列表，判断是否存在表征第二状态的状态描述符，直至不存在时，停止所述循环搜索，释放容器中变化前的模型文件，并从所述目录加载变化后的模型文件，然后进行初始化；初始化完成后，将状态描述列表中所有表征第三状态的状态描述符修改为表征第一状态的状态描述符；

接收所述推理服务端返回的计算结果；

将所述计算结果发送给所述客户端。

2.根据权利要求1所述的方法，其特征在于：

所述容器集群管理系统为Kubernetes，所述容器为Docker容器；

通过Service的开放端口接收所述请求信息以及发出所述计算结果。

3.根据权利要求1所述的方法，其特征在于：

所述请求信息包括待处理的图像数据；

当请求调用的函数信息包括单帧分割函数信息时，响应于所述计算指令，所述推理服务端执行以下操作：

接收所述图像数据作为参数；

对待处理图像数据进行预处理操作；

选择处于第一状态的、用于进行单帧分割的模型，并将其状态描述符修改为表征第二状态的状态描述符；

调用该模型对预处理后的图像数据进行推理，获得推理数据；

将该模型的状态描述符修改为表征第一状态的状态描述符，并对所述推理数据进行后处理，得到所述计算结果。

4.根据权利要求1所述的方法，其特征在于：

所述请求信息包括待处理的图像数据；

当请求调用的函数信息包括单帧检测函数信息时，响应于所述计算指令，所述推理服务端执行以下操作：

接收所述图像数据作为参数；

对待处理图像数据进行预处理操作；

选择处于第一状态的、用于进行单帧检测的模型，并将其状态描述符修改为表征第二状态的状态描述符；

调用该模型对预处理后的图像数据进行推理，获得推理数据；

将该模型的状态描述符修改为表征第一状态的状态描述符，并对所述推理数据进行后处理，得到所述计算结果。

5.根据权利要求1所述的方法，其特征在于：

所述请求信息包括待处理的视频数据；

当请求调用的函数信息包括视频分割函数信息时，响应于所述计算指令，所述推理服务端执行以下操作：

根据所述待处理的视频数据获得视频路径；

根据所述视频路径将待处理的视频信息拉取到本地；

读取所述视频信息，依次对视频帧进行预处理操作；

选取处于第一状态的、用于进行视频分割的模型，并其状态描述符修改为表征第二状态的状态描述符；

调用该模型对预处理后的视频帧进行推理，获得推理数据；

对所有视频帧的推理数据进行后处理，写入结果视频文件；

将该模型的状态描述符修改为表征第一状态的状态描述符；

删除本地视频文件，并上传所述结果视频文件，获得结果视频路径作为所述计算结果。

6.根据权利要求1所述的方法，其特征在于：

所述请求信息包括待处理的视频数据；

当请求调用的函数信息包括视频检测函数信息时，响应于所述计算指令，所述推理服务端执行以下操作：

根据所述待处理的视频数据获得视频路径；

根据所述视频路径将待处理的视频信息拉取到本地；

读取所述视频信息，依次对视频帧进行预处理操作；

选取处于第一状态的、用于进行视频检测的模型，并其状态描述符修改为表征第二状态的状态描述符；

调用该模型对预处理后的视频帧进行推理，获得推理数据；

对所有视频帧的推理数据进行后处理，写入TXT结果文件；

将该模型的状态描述符修改为表征第一状态的状态描述符；

删除本地视频文件，并上传所述TXT结果文件，获得TXT结果文件路径作为所述计算结果。

7.提供GPU服务的系统，其特征在于，包括以下模块：

容器管理模块，用于在容器集群管理系统中启动容器；

服务端加载模块，用于读取配置信息并根据所述配置信息加载容器中的推理服务端；

服务对接模块，用于执行以下步骤：

接收客户端的请求信息，根据所述请求信息向所述推理服务端发送计算指令，所述计算指令用于指示所述推理服务端调用基于Caffe框架部署的模型在GPU上进行推理；所述请求信息包括请求调用的函数信息；接收所述请求信息后，判断所述推理服务端是否存在所述请求调用的函数；若存在，则向所述推理服务端发送所述计算指令；若不存在，则向所述客户端返回错误信息；

所述“加载容器中的推理服务端”包括以下步骤：获取显存信息，并据此配置线程数量，所述配置信息包括所述线程数量；将供所述客户端调用的函数绑定到所述推理服务端；根据所述请求信息以及所述线程数量，选择对应类型以及数量的模型进行初始化，所述初始化的模型的数量与所述线程数量保持一致；

生成状态描述列表，所述状态描述列表用于记录容器中加载的每一份模型文件与状态描述符的对应关系；不同类型的所述状态描述符分别用于表征的状态至少包括第一状态、第二状态以及第三状态；所述第一状态示意所述模型文件处于空闲的状态；所述第二状态示意所述模型文件处于被调用进行推理的状态；所述第三状态示意所述模型文件处于更新中的状态；响应于检测指令，对存放所述模型文件的目录进行检测，判断所述目录内的文件是否发生变化，若是，则持续将所有表征第一状态的状态描述符修改为表征第三状态的状态描述符；循环搜索所述状态描述列表，判断是否存在表征第二状态的状态描述符，直至不存在时，停止所述循环搜索，释放容器中变化前的模型文件，并从所述目录加载变化后的模型文件，然后进行初始化；初始化完成后，将状态描述列表中所有表征第三状态的状态描述符修改为表征第一状态的状态描述符；接收所述推理服务端返回的计算结果；将所述计算结果发送给所述客户端。

Images