本文最初发表于 Cortex 网站，经原作者 Caleb Kaiser 许可由 InfoQ 中文站翻译分享。
对于模型部署来讲，AWS Lambda 是一个很有吸引力的方案。从表面上来看，其收益是很明显的。Lambda 可以：
但是，问题在于，尽管这都是 serverless 架构的收益，但是像 Lambda 这样的通用 serverless 平台通常会有一些限制，这些限制使得它并非机器学习的最理想方案。
我们亲身体会到这一点。在着手实现 Cortex 之前，我们曾经尝试通过 Lambda 运行部署。事实上，正是由于 Lambda 的不足，在一定程度上促使我们建立一个专门用于机器学习的 serverless 计算平台。
1Lambda 不能部署大型的模型（比如 Transformer 模型）现在，你可能已经读过很多关于机器学习模型增长的文章了。可以说，在很多适用于机器学习的领域，尤其是自然语言处理方面，模型正在迅速地变得越来越大。
例如，在过去几年中，Hugging Face 的 Transformers 库成为了最受欢迎的 NLP 库。从传闻中看到，用户经常在生产 API 中使用它。这个库为如下的模型提供了便利的接口：
GPT-2：完全训练后大约是 6GB
BlenderBot：完全训练后大约是 5GB
RoBERTa：完全训练后大于 1GB
而这仅仅是看上去比较合理的模型。有些模型，比如 T5，可能会超过 40GB，不过我承认，自己没有遇到过太多团队大规模地部署这种规模的模型。
适用于现代机器学习需求的 serverless 平台需要能部署大型的模型，但是 Lambda 做不到这一点。Lambda 限制部署包的大小为未压缩的 250MB，并将函数限制到了 30008 MB 的内存。如果你想运行任何一种最先进的语言模型，Lambda 都不是合适的可选方案。
随着模型变得越来越大，它们的资源需求也会随之增加。对我们前文所讨论的一些大模型来说，使用 GPU 推理是唯一能以接近实时延迟的速度处理它们的方式。
类似的，像 Inferentia 和 TPU 这样的 ASIC 在某些情况下正在改变模型处理的经济效益，并且随着它们的不断成熟，有潜力在更大的范围实现这一点。即使是相对比较年轻的方案，但是我们已经对某些模型的性能进行了基准测试，使用 Inferentia 的效率能提高一个数量级。
在过去，GPU/ASIC 推理被认为是相对小众的场景，但是它正在越来越多地成为机器学习工程的标准。令人遗憾的是，Lambda 并不支持它。
对大量的 Cortex 用户来说，仅凭这一点就让 Lambda 失去了将模型部署到生产环境的机会。
Lambda 实例能够服务于连续的请求，但不能处理并发的请求。在处理模型的时候，这是一个大问题。
推理是一项计算成本高昂的任务，通常伴随大量的延迟（因此经常需要 GPU/ASIC）。为了防止推理成本的飙升，很重要的一点就是在分配计算资源的时候，要尽可能保持高效，同时不能对延迟产生负面影响。
在 Cortex 中，我们实现这一点的方式是提供预测前和预测后的钩子，它们可以异步执行代码。通常来讲，当一些 IO 请求（比如从数据库中调用用户信息、写入日志等）与推理函数相连接的时候，就会用到它。
这些异步钩子提供的优势在于，它允许我们在预测生成后立即释放推理所需的资源，而不必等到响应发送之后。
然而，在 Lambda 中，这是不可能实现的。
因此，如果使用 Lambda 处理模型的话，很可能会因为每个实例上闲置的资源浪费而导致过度扩展。
4机器学习需要一个专门的 serverless 平台Serverless 架构天然适合模型部署。但问题在于，我们在适用于 MLOps 的任何场景中都会遇到的问题是，机器学习的需求非常具体，使得流行的 DevOps 工具（如 Lambda）并不适用。
我们构建 Cortex 的部分使命就是构建一个平台，提供我们在 Lambda 中喜爱的易用性，同时解决 ML 基础设施的具体挑战。
https://www.cortex.dev/post/serverless-machine-learning-aws-lambda答应我，从今以后这样打开InfoQ
2021 年前端开发的下一步发展预测
被接连封杀后，出海的“TikTok们”还在坚持什么？
InfoQ 写作平台欢迎所有热爱技术、热爱创作、热爱分享的内容创作者入驻！
还有更多超值活动等你来！
扫描下方二维码
填写申请，成为作者
点个在看少个 bug 👇
