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

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

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

• 让数据科学家和机器学习工程师在部署时无需管理基础设施

• 在最大化可用性的同时，能将成本降到最低

• 为定义预测 API 提供了一个简单的接口

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

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

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

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

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

• GPT-2：完全训练后大约是 6GB

• BlenderBot：完全训练后大约是 5GB

• RoBERTa：完全训练后大于 1GB

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

适用于现代机器学习需求的 serverless 平台需要能部署大型的模型，但是 Lambda 做不到这一点。Lambda 限制部署包的大小为未压缩的 250MB，并将函数限制到了 30008 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 基础设施的具体挑战。

原文链接：

https://www.cortex.dev/post/serverless-machine-learning-aws-lambda