我们为何转向 Hugging Face 推理端点,以及您或许也该如此的原因
Hugging Face 最近推出了推理端点 (Inference Endpoints);用他们的话说:解决了 transformers 在生产环境中的问题。推理端点是一种托管服务,它允许你
- 部署 Hugging Face Hub 上的(几乎)任何模型
- 部署到任何云平台(AWS 和 Azure,GCP 即将支持)
- 部署到各种实例类型(包括 GPU)
- 我们正在将一些在 CPU 上进行推理的机器学习(ML)模型迁移到这项新服务上。这篇博客文章将探讨我们这样做的原因,以及为什么您可能也想考虑这样做。
我们过去是怎么做的?
在我们迁移到推理端点之前,这些模型是由内部管理的,运行在由 AWS Fargate 支持的 AWS 弹性容器服务 (ECS) 上。这为你提供了一个可以运行基于容器任务的无服务器集群。我们的流程如下:
- 在 GPU 实例上训练模型(由 CML 配置,使用 transformers 进行训练)
- 上传到 Hugging Face Hub
- 构建 API 以提供模型服务 (FastAPI)
- 将 API 包装在容器中 (Docker)
- 将容器上传到 AWS 弹性容器仓库 (ECR)
- 将模型部署到 ECS 集群
现在,你可以合理地争辩说,ECS 并不是提供 ML 模型的最佳方法,但它至今为止一直为我们服务,并且还允许 ML 模型与其他基于容器的服务并存,因此减少了认知负担。
我们现在是怎么做的?
有了推理端点,我们的流程是这样的:
- 在 GPU 实例上训练模型(由 CML 配置,使用 transformers 进行训练)
- 上传到 Hugging Face Hub
- 使用 Hugging Face 推理端点进行部署。
所以这要简单得多。我们也可以使用其他托管服务,如 SageMaker、Seldon 或 Bento ML 等,但由于我们已经将模型上传到 Hugging Face Hub 作为模型注册中心,并且我们在 Hugging Face 的其他工具(如 transformers 和 AutoTrain)上投入颇深,因此使用推理端点对我们来说非常有意义。
延迟和稳定性如何?
在切换到推理端点之前,我们使用 ab 测试了不同的 CPU 端点类型。
对于 ECS,我们没有进行那么广泛的测试,但我们知道一个大型容器从同一区域的实例调用时的延迟约为 200 毫秒。我们对推理端点的测试是基于在 RoBERTa 上微调的文本分类模型,测试参数如下:
- 请求者区域:eu-east-1
- 请求者实例大小:t3-medium
- 推理端点区域:eu-east-1
- 端点副本数:1
- 并发连接数:1
- 请求数:1000(对于这个特定应用,即使是单个连接,在 1-2 分钟内发出 1000 个请求也代表着非常高的使用率)
下表显示了四种配备英特尔 Ice Lake 的 CPU 端点的延迟(毫秒 ± 标准差)和完成测试所需的时间(秒)。
size | vCPU (cores) | Memory (GB) | ECS (ms) | 🤗 (ms)
----------------------------------------------------------------------
small | 1 | 2 | _ | ~ 296
medium | 2 | 4 | _ | 156 ± 51 (158s)
large | 4 | 8 | ~200 | 80 ± 30 (80s)
xlarge | 8 | 16 | _ | 43 ± 31 (43s)
从这些结果中我们看到的情况非常鼓舞人心。将使用这些端点的应用程序是实时处理请求的,所以我们需要尽可能低的延迟。我们可以看到,原生的 Hugging Face 容器比我们在 ECS 上运行的定制容器快两倍多 —— 我们从大型推理端点收到的最慢响应也只有 108 毫秒。
成本如何?
那么这一切的成本是多少呢?下表显示了我们以前的做法(ECS + Fargate)和使用推理端点的价格比较。
size | vCPU | Memory (GB) | ECS | 🤗 | % diff
----------------------------------------------------------------------
small | 1 | 2 | $ 33.18 | $ 43.80 | 0.24
medium | 2 | 4 | $ 60.38 | $ 87.61 | 0.31
large | 4 | 8 | $ 114.78 | $ 175.22 | 0.34
xlarge | 8 | 16 | $ 223.59 | $ 350.44 | 0.5
关于这一点,我们可以说几件事。首先,我们想要一个托管的部署解决方案,我们还没有一个专门的 MLOps 团队,所以我们正在寻找一个能帮助我们最大限度地减少部署模型时间的解决方案,即使它的成本比自己处理部署要高一点。
推理端点比我们以前的做法更贵,成本增加了 24% 到 50%。在我们目前的运营规模下,这点额外成本——一个大型 CPU 实例每月约 60 美元的差额——与我们通过不必担心 API 和容器而节省的时间和认知负担相比,简直是微不足道。如果我们要部署数百个 ML 微服务,我们可能需要重新考虑,但这对于许多托管方法来说可能都是如此。
一些说明和注意事项:
- 您可以在这里找到推理端点的定价,但是当您从 GUI 部署新端点时会显示一个不同的数字。我用的是后者,价格更高。
- 我在表中为 ECS + Fargate 提供的数值是低估的,但可能相差不大。我从 Fargate 定价页面提取了这些数据,它只包括托管实例的成本。我没有包括数据传入/传出(可能最大的一项是从 Hugging Face Hub 下载模型),也没有包括与 ECR 相关的成本。
其他考量
部署选项
目前,您可以通过 GUI 或使用 RESTful API 部署推理端点。您还可以使用我们的命令行工具 hugie(这将是未来博客的主题),通过传递一个配置,用一行代码启动推理端点,真的就这么简单:
hugie endpoint create example/development.json
对我来说,所缺少的是一个自定义的 Terraform 提供者。像我们一样,使用 hugie 从 GitHub action 部署推理端点是很好,但如果我们能使用 Terraform 这个强大的状态机来跟踪这些,那就更好了。我很确定有人(如果不是 Hugging Face 的话)很快就会写一个——如果没人写,我们就会写。
在单个端点上托管多个模型
Philipp Schmid 发表了一篇非常好的博客,讲述了如何编写一个自定义的 端点处理器 (Endpoint Handler) 类,从而允许您在单个端点上托管多个模型,这可能会为您节省一大笔钱。他的博客是关于 GPU 推理的,唯一真正的限制是您能将多少个模型装入 GPU 内存。我猜想这也适用于 CPU 实例,尽管我还没试过。
总结…
我们发现 Hugging Face 推理端点是将 transformer(和 sklearn)模型部署到端点以便被应用程序使用的一种非常简单方便的方法。虽然它们的成本比我们之前使用的 ECS 方法要高一些,但这非常值得,因为它节省了我们思考部署的时间,我们可以专注于我们想做的事情:为我们的客户构建 NLP 解决方案以帮助他们解决问题。
如果您对贵公司的 Hugging Face 推理端点感兴趣,请在此处联系我们 - 我们的团队将与您联系以讨论您的需求!
本文最初于 2023 年 2 月 15 日发表于 Medium。