前言为了进行机器学习工程，您首先部署一个模型，在大多数情况下作为预测API。为了让这个API在生产中工作，必须首先构建模型服务基础设施。这包括负载平衡、缩放、监控、更新等。乍一看，所有这些工作似乎都很熟悉。多年来，Web开发人员和DevOps工程师一直在自动化微服务基础设施。我们当然可以重新利用他们的工具？不幸的是，我们不能。虽然ML的基础设施类似于传统的DevOps，但它对ML来说足够具体，使得标准的DevOps工具不太理想。这就是我们开发Cortex的原因——一个用于机器学习工程的开源平台。在一个非常高的层次上，Cortex旨在简化本地或云端的模型部署，从而自动化所有底层基础设施。该平台的核心组件是PredictorInterface——一个可编程的Python接口，开发人员可以通过它编写预测API。专门设计一个Python接口来为Web请求提供预测是一项挑战，我们花了几个月的时间（并且仍在完善中）。在这里，我想分享一些我们制定的设计原则：1.预测器只是一个Python类。Cortex的核心是我们的预测器，它本质上是一个预测API，包括所有的请求处理代码和依赖。预测器接口实现了这些预测API的一些简单要求。由于Cortex采用微服务方法来提供模型服务，因此预测器接口严格关注两件事：初始化模型以提供预测在这种精神下，Cortex的预测接口需要两个函数，其余的init__()和predict()，它们或多或少做你期望的事情：importtorchfromtransformersimportpipelineclassPythonPredictor:def__init__(self,config):#UseGPUs,ifavailabledevice=0iftorch.cuda.is_available()else-1#Initializemodelself.summarizer=pipeline(task="summarization",device=device)defpredict(self,payload):#Generatepredictionsummary=self.summarizer(payload["text"],num_beams=4,length_penalty=2.0,max_length=142,no_repeat_ngram_size=3)#Returnpredictionreturnssummary[0]["summary_text"]初始化后即可将预测器想象成一个Python对象，当用户查询端点时，它的单个predict()函数被调用。这种方法的一大好处是它对任何有软件工程经验的人来说都是直观的。无需接触数据管道或模型训练代码。模型只是一个文件，预测器只是一个导入模型并运行predict()方法的对象。然而，除了其句法吸引力之外，这种方法在如何补充更广泛的皮质方法方面提供了一些关键优势。2.预测只是一个HTTP请求在生产中构建用于预测服务的接口的复杂性之一是输入几乎肯定与模型的训练数据不同，至少在格式上是这样。这在两个层面上起作用：POST请求的主体不是NumPy数组，也不是您的模型旨在处理的任何数据结构。机器学习工程就是使用模型构建软件，这通常意味着使用模型来处理未经训练的数据，例如使用GPT-2创作民谣音乐。因此，预测器接口不能对预测API的输入和输出发表意见。预测只是一个HTTP请求，开发人员可以用它做任何他们想做的事情。例如，如果他们想部署一个多模型端点并根据请求参数查询不同的模型，他们可以这样做：")self.summarizer=pipeline(task="summarization")defpredict(self,query_params,payload):model_name=query_params.get("model")ifmodel_name=="sentiment":returnsself.analyzer(payload["text"])[0]elifmodel_name==“summarizer”:summary=self.summarizer(payload["text"])[0]else:returnJSONResponse({"error":f"unknownmodel:{model_name}"},status_code=400)尽管这个接口让开发人员可以自由地使用他们的API做他们想做的事情，但它也提供了一些自然的范围，让Cortex对其基础设施更加自以为是。例如，在幕后，Cortex使用FastAPI来设置请求路由。Cortex在这一层设置了很多与自动排序、监控等基础功能相关的进程，如果开发者需要实现路由，就会变得非常复杂。但是，因为每个API都有一个predict()方法，所以每个API都有相同数量的路由——1。假设这允许Cortex在基础架构级别做更多事情而不会限制工程师。3.服务模型只是一个微服务对于任何在生产中使用机器学习的人来说，规模是一个主要问题。模型可能很大（GPT-2大约为6GB）、计算成本高，并且可能具有高延迟。特别是对于实时推理，扩大规模以处理流量是一项挑战——如果您的预算紧张，则更是如此。为了解决这个问题，Cortex将预测器视为可以水平扩展的微服务。更具体地说，当开发人员进行Cortex部署时，Cortex将包含API，启动集群进行推理，然后进行部署。然后它将API作为负载均衡器后面的Web服务公开，并配置自动缩放、更新和监控：预测器接口是此过程的基础，尽管它“只是”一个Python接口。预测器接口所做的是强制打包代码，使其成为一个单一的原子推理单元。单个API所需的所有请求处理代码都包含在预测器中。这使得大脑皮层可以轻松测量预测因子。这样，工程师就不必做任何额外的工作——除非他们当然想做一些调整——来准备用于生产的API。默认情况下，Cortex部署已准备就绪。
