我们为什么构建自己的serverless机器学习平台，而不是使用AWS Lambda

摘要

Lambda是一个通用且流行的serverless平台，但是面对机器学习的具体场景，它有一定的不足之处，本文分析了机器学习对serverless的特殊需求并简要介绍了Cortex这一适用于机器的专用serverless平台。

本文最初发表于Cortex网站，经原作者Caleb Kaiser许可由InfoQ中文站翻译分享。

对于模型部署来讲，AWS Lambda是一个很有吸引力的方案。从表面上来看，其收益是很明显的。Lambda能够：

• 让数据科学家和机器学习工程师在部署的时候，不需要管理基础设施
• 在最大化可用性的同时，能够将成本降到最低
• 为定义预测API提供了一个简单的接口

但是，问题在于，尽管这都是serverless架构的收益，但是像Lambda这样的通用serverless平台通常会有一些限制，这些限制使得它并不是机器学习的理想方案。

我们亲身体会到了这一点。在开始着手实现Cortex之前，我们曾经尝试通过Lambda运行部署。事实上，正是由于Lambda的不足，在一定程度上促使我们建立一个专门用于机器学习的serverless计算平台。

Lambda的缺点包括：

Lambda不能部署大型的模型（比如Transformer模型）

现在，你可能已经读过很多关于机器学习模型增长的文章了。可以说，在很多适用于机器学习的领域，尤其是自然语言处理方面，模型正在迅速地变得越来越大。

例如，在过去的几年中，Hugging Face的Transformers库成为了最受欢迎的NLP库。从传闻中看到，用户经常在生产API中使用它。这个库为如下的模型提供了便利的接口：

• GPT-2：完全训练后大约是6GB
• BlenderBot：完全训练后大约是5GB
• RoBERTa：完全训练后大于1GB

而这仅仅是看上去比较合理的模型。有些模型，比如T5，可能会超过40GB，不过我承认，我没有遇到过太多团队大规模地部署这种规模的模型。

适用于现代机器学习需求的serverless平台需要能够部署大型的模型，但是Lambda做不到这一点。Lambda限制部署包的大小为未压缩的250MB，并将函数限制到了3,0008 MB的内存。如果你想运行任何一种最先进的语言模型，Lambda都不是合适的可选方案。

为了进行模型处理，需要GPU/ASIC的支持

随着模型变得越来越大，它们的资源需求也会随之增加。对于我们前文所讨论的一些大模型来说，使用GPU推理是唯一能够以接近实时延迟的速度处理它们的方式。

类似的，像Inferentia和TPU这样的ASIC在某些情况下正在改变模型处理的经济效益，并且随着它们的不断成熟，有潜力在更大的范围实现这一点。即使是相对比较年轻的方案，但是我们已经对某些模型的性能进行了基准测试，使用Inferentia的效率能够提高一个数量级。

在过去，GPU/ASIC推理被认为是相对小众的场景，但是它正在越来越多地成为机器学习工程的标准。令人遗憾的是，Lambda并不支持它。

对于大量的Cortex用户来说，仅凭这一点就使得Lambda失去了将模型部署到生产环境的机会。

Lambda处理模型的效率太低

Lambda实例能够服务于连续的请求，但不能处理并发的请求。在处理模型的时候，这是一个大问题。

推理是一项计算成本高昂的任务，通常伴随大量的延迟（因此经常需要GPU/ASIC）。为了防止推理成本的飙升，很重要的一点就是在分配计算资源的时候，要尽可能保持高效，同时不能对延迟产生负面影响。

在Cortex中，我们实现这一点的方式是提供预测前和预测后的钩子，它们可以异步执行代码。通常来讲，当一些IO请求（比如从数据库中调用用户信息，写入日志等）与推理函数相连接的时候，就会用到它。

这些异步钩子提供的优势在于，它允许我们在预测生成后立即释放推理所需的资源，而不必等到响应发送之后。

然而，在Lambda中，这是不可能实现的。

因此，如果使用Lambda处理模型的话，很可能会因为每个实例上闲置的资源浪费而导致过度扩展。

机器学习需要一个专门的serverless平台

serverless架构天然适合模型部署。但问题在于，我们在适用于MLOps的任何场景中都会遇到的问题是，机器学习的需求非常具体，使得流行的DevOps工具（如Lambda）并不适用。

我们构建Cortex的部分使命就是构建一个平台，提供我们在Lambda中喜爱的易用性，同时解决ML基础设施的具体挑战。

如果你觉得这个挑战很有意思的话，那我要说我们一直在寻找新的贡献者。