无服务器机器学习：应该在哪里存储他们的模型？

Posted 2023-03-08

【中文标题】无服务器机器学习：应该在哪里存储他们的模型？

【英文标题】：Serverless machine learning: where should one store their models?

【发布时间】：2021-09-15 03:45:45

【问题描述】：

我正在部署一个使用 BERT 制作的无服务器 NLP 应用。我目前正在使用无服务器框架和 AWS ECR 来克服 250 MB 的 AWS Lambda 部署包限制（PyTorch 已经占用了超过该空间）。

我对这个解决方案非常满意，因为它让我可以简单地将我的应用程序化、上传到 ECR，而无需担心其他任何事情。

我的一个疑问是我应该将模型存储在哪里。我的应用程序使用 3 个不同的保存模型，每个模型的大小为 422 MB。我有两个选择：

在 docker 镜像中复制我的模型。

优点：如果我重新训练我的模型，它将在我重新部署应用程序时自动更新，并且我不必使用 AWS SDK 从 S3 加载对象 缺点：Docker 镜像非常大

将我的模型存储在 S3 中：

优点：图像大小比其他解决方案小（1+ GB vs 3+ GB） 缺点：如果我重新训练我的模型，我需要在 S3 上手动更新它们，因为它们与应用程序部署管道分离。我还需要使用 AWS SDK 从 S3 加载它们（可能会增加一些开销？）。

所以我的问题最终是：在这两种解决方案中，哪一种是最佳做法？为什么，为什么不呢？是否有最佳实践，还是基于偏好/需要？

【参考方案1】：

第三个选项可能对您很有帮助：将您的模型存储在 EFS 卷上。

EFS 卷就像您可以附加到 Lambda 的附加硬盘驱动器。它们的大小可以随心所欲。

训练完模型后，只需将其复制到 EFS 卷即可。您将 Lambda 配置为在 EFS 卷启动时挂载该卷，瞧，您的模型无需任何模糊即可使用。不能从 S3 复制或将其放入 Docker 映像中。并且同一个 EFS 卷可以同时挂载到多个 Lambda。

要了解更多信息，请阅读：

Announcement blog post Documentation

---

25.08.2021 更新

用户@wtfzamba 尝试了此解决方案，但遇到了其他人可能感兴趣的限制：

我确实尝试了您建议的解决方案。它运作良好，但只是在一定程度上，我指的是性能。在我的情况下，当我进行批量分类时，我需要能够同时启动约 100 个 lambda，以加快处理过程。问题是 EFS 吞吐量上限不是每个连接，而是总数。因此，我被允许的 300MB/s 突发吞吐量似乎由每个 lambda 实例共享，此时甚至在能够将模型加载到内存之前就超时了。

选择此选项时请记住这一点。

【讨论】：

我知道如果我没有发现我可以使用 ECR，EFS 将成为我的替代方案。但是，我不确定向堆栈添加另一个元素的好处是否超过使用 ECR 的缺点。还有其他我不知道的优势吗？

@wtfzambo 这是一个很难回答的问题。解决方案对您的效果如何通常取决于您的限制条件和您的（团队）技能。我认为这两个选项（Docker 和 EFS）都是完全有效的。我的直觉告诉我，带有 EFS 的“纯”Lambda 更易于管理，而且使用 X-Ray 等其他服务进行监控也可能更容易。我也认为使用“本机” Lambdas 冷启动应该更快（但我还没有测量）。但如果这些真的是不使用 Docker 的好理由……我不确定。我会继续使用您当前的解决方案，只有当您感到“痛苦”时才尝试 EFS。

谢谢，我完全明白了。我将通过一个预热功能来解决冷启动问题，因为在内存中加载 1.5GB 的模型需要一些时间，而且由于这个模型需要上我们的网站供用户使用，我当然不能指望他们等待超过 5 秒让它返回一些结果。

@wtfzambo 你应该自己写一个问题的答案，列出你的思考过程和你最终做了什么。你甚至可以接受这个答案。这将有助于其他人做出决定。

关于 EFS 的小更新。我确实尝试了您建议的解决方案。它运作良好，但只是在一定程度上，我指的是性能。在我的情况下，当我进行批量分类时，我需要能够同时启动约 100 个 lambda，以加快处理过程。问题是 EFS 吞吐量上限不是每个连接，而是总数。因此，我被允许的 300MB/s 突发吞吐量似乎由每个 lambda 实例共享，此时甚至在能够将模型加载到内存之前就超时了。