我們為何轉向 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。