为什么我们正在转向Hugging Face推理终端，并且也许您也应该这样做
为什么我们转向Hugging Face推理终端，您也应该这样做
Hugging Face最近推出了Inference Endpoints; 他们称之为：解决了在生产环境中使用transformers。Inference Endpoints是一项托管服务，可以让您：
- 部署（几乎）任何模型在Hugging Face Hub上
- 部署到任何云平台（AWS，Azure，GCP正在开发中）
- 在各种实例类型上运行（包括GPU）
- 我们正在将一些在CPU上进行推理的机器学习（ML）模型切换到这项新服务上。本博客将介绍为什么要切换，以及为什么您可能也想考虑使用它。
我们之前在做什么？
我们已经切换到Inference Endpoints的模型之前，这些模型之前是由我们内部管理，并在AWS Elastic Container Service（ECS）上运行，由AWS Fargate支持。这为您提供了一个可以运行基于容器的任务的无服务器集群。我们的过程如下：
- 在GPU实例上训练模型（使用transformers进行训练）
- 上传到Hugging Face Hub
- 构建用于提供模型的API（FastAPI）
- 将API封装在容器中（Docker）
- 将容器上传到AWS Elastic Container Repository（ECR）
- 部署模型到ECS集群
现在，您可以合理地争论ECS并不是为提供ML模型而采用的最佳方式，但它一直服务于我们，也允许ML模型与其他基于容器的服务并存，因此减少了认知负荷。
我们现在要做什么？
使用Inference Endpoints，我们的流程如下：
- 在GPU实例上训练模型（使用transformers进行训练）
- 上传到Hugging Face Hub
- 使用Hugging Face Inference Endpoints进行部署。
所以这样要简单得多。我们也可以使用其他托管服务，如SageMaker、Seldon或Bento ML等，但由于我们已经将模型上传到了Hugging Face hub作为模型注册表，并且我们对Hugging Face的其他工具（如transformers和AutoTrain）已经投入了很多，所以对我们来说使用Inference Endpoints非常合理。
延迟和稳定性如何？
在切换到Inference Endpoints之前，我们使用ab测试了不同类型的CPU端点。
对于ECS，我们没有进行太多的测试，但我们知道一个大型容器在同一地区的实例上的延迟约为200毫秒。我们对Inference Endpoints进行的测试是基于RoBERTa进行微调的文本分类模型，测试参数如下：
- 请求者地区：eu-east-1
- 请求者实例大小：t3-medium
- Inference端点地区：eu-east-1
- 端点副本：1
- 并发连接数：1
- 请求数：1000（即使从单个连接进行1-2分钟的1000个请求，对于此特定应用程序来说也代表了非常重的使用）
下表显示了四个配备Intel Ice Lake的CPU端点的延迟（毫秒±标准差）和测试完成时间（秒）。
size | vCPU (cores) | Memory (GB) | ECS (ms) | 🤗 (ms)
----------------------------------------------------------------------
small | 1 | 2 | _ | ~ 296
VoAGI | 2 | 4 | _ | 156 ± 51 (158s)
large | 4 | 8 | ~200 | 80 ± 30 (80s)
xlarge | 8 | 16 | _ | 43 ± 31 (43s) 从这些结果中我们可以看到令人鼓舞的情况。将使用这些端点的应用程序以实时方式提供请求，因此我们需要尽可能低的延迟。我们可以看到，与我们在ECS上运行的定制容器相比，vanilla Hugging Face容器的速度快了两倍多，我们从大型Inference Endpoint收到的最慢响应时间仅为108毫秒。
成本如何？
那么这一切的成本是多少？下表显示了我们之前所做的（ECS + Fargate）与使用Inference Endpoints的价格比较。
规模 | 虚拟核心数 | 内存（GB） | ECS | 🤗 | % 差异
----------------------------------------------------------------------
小型 | 1 | 2 | $ 33.18 | $ 43.80 | 0.24
VoAGI | 2 | 4 | $ 60.38 | $ 87.61 | 0.31
大型 | 4 | 8 | $ 114.78 | $ 175.22 | 0.34
超大型 | 8 | 16 | $ 223.59 | $ 350.44 | 0.5 我们可以对此进行一些评论。首先，我们希望有一个托管的部署解决方案，因为我们还没有专门的 MLOPs 团队，所以我们正在寻找一种能够帮助我们最小化部署模型所需时间的解决方案，即使它的成本比自行处理部署要高一些。
推理端点的成本比我们之前的做法更高，增加了24%到50%的费用。在我们目前运营的规模下，这额外的费用，即对于大型 CPU 实例每月约60美元的差异，与不必担心 API 和容器所节省的时间和认知负荷相比，微不足道。如果我们部署数百个机器学习微服务，我们可能需要重新考虑，但这可能适用于许多托管方法。
一些说明和注意事项：
- 您可以在这里找到推理端点的定价，但在通过 GUI 部署新端点时会显示不同的数字。我使用了后者，它更高。
- 我在表格中呈现的 ECS + Fargate 的值是一个低估值，但可能差别不大。我从 Fargate 定价页面提取它们，其中只包括托管实例的成本。我没有包括数据进出（从 Hugging Face Hub 下载模型可能是最大的事情之一），也没有包括与 ECR 相关的成本。
其他考虑因素
部署选项
目前，您可以通过 GUI 或使用 RESTful API 部署推理端点。您还可以使用我们的命令行工具 hugie（将成为未来博客的主题）通过传递配置来一行代码启动推理端点，非常简单：
hugie endpoint create example/development.json对我来说，缺少的是自定义的terraform提供程序。用hugie从GitHub操作中部署推理端点是很好的，正如我们所做的那样，但如果我们能够使用令人惊叹的terraform状态机来跟踪这些操作，那将更好。我相信很快会有人（如果不是Hugging Face）编写一个terraform提供程序，如果没有，我们将会写。
在单个端点上托管多个模型
Philipp Schmid 发表了一篇关于如何编写自定义 Endpoint Handler 类的博客，允许您在单个端点上托管多个模型，从而可能为您节省相当多的费用。他的博客是关于 GPU 推理的，唯一的限制是您可以将多少个模型放入 GPU 内存中。我认为这也适用于 CPU 实例，尽管我还没有尝试过。
最后…
我们发现 Hugging Face 推理端点是一种非常简单和便捷的方式，可以将 Transformer（和 sklearn）模型部署到端点上，以便应用程序可以使用它们。尽管它们的成本比我们之前使用的 ECS 方法要高一些，但它非常值得，因为它节省了我们思考部署的时间，我们可以专注于我们想要的东西：为客户构建自然语言处理解决方案，帮助解决他们的问题。
如果您对将 Hugging Face 推理端点用于您的公司感兴趣，请在此处联系我们 – 我们的团队将与您联系以讨论您的需求！
本文最初发布于2023年2月15日的 VoAGI。
