在 Google Cloud 上部署 Serverless Transformers Pipeline

A Hugging Face 社群成員 Maxence Dominici 詳細介紹了一種在 Google Cloud Platform (GCP) 上部署情緒分析微服務的工作流程。最終的實作採用了透過 Google Cloud Run 的 serverless 架構，使得 distilbert-base-uncased-finetuned-sst-2-english 模型在低流量請求模式下能夠以具成本效益的方式進行部署。

透過 Google Cloud Run 進行 Serverless 部署

選擇 Google Cloud Run 作為生產環境，是因為它允許靈活的記憶體與 vCPU 配置，這對於載入 transformer 模型而言是必要的。最終的架構包含一個封裝在 Docker 容器中的 Flask 應用程式，並以託管服務的形式進行部署。

技術組件

  • Model: 使用了 distilbert-base-uncased-finetuned-sst-2-english 模型，特別是 PyTorch 版本 (pytorch_model.bin, config.json, 以及 vocab.txt)。
  • Application Logic: main.py 檔案處理 GET 請求，需要一個評論字串與一個用於基本安全性的 API key。
  • Containerization: 基於 python:3.7 的 Dockerfile 使用 gunicorn 作為進入點來提供 Flask 應用程式服務。
  • Dependencies: 環境需要 Flask==1.1.2, torch===1.7.1, transformers~=4.2.0, 以及 gunicorn>=20.0.0。

資源配置

為了避免記憶體錯誤並控制成本，實例配置如下：

  • Memory: 從預設的 256 MB 升級至 4 GB。
  • Concurrency: Gunicorn 配置設定為 --workers 1 --threads 1。這確保了只有一個程序與一個執行緒在運作，防止多個實例消耗過多記憶體並增加帳單費用。

GCP 服務評估

在決定使用 Cloud Run 之前，測試了幾種 Google Cloud 服務，以確定部署 Hugging Face pipeline 最可行的路徑：

Service Outcome Reason for Rejection
AI-Platform Prediction Failed 模型是一個 checkpoint，而非「純 TensorFlow」的 saved model；且遇到了 beta 版的穩定性問題。
App Engine Failed 在安裝 TensorFlow 時遇到了缺失的系統依賴檔案；PyTorch 可以運作，但每個實例無法處理超過兩個請求。
Cloud Run Success 透過 Docker 映像檔提供了必要的記憶體與 vCPU 控制。

效能與成本分析

Latency

請求處理通常花費不到五秒，包含模型載入與預測。冷啟動 (Cold starts) 可能會增加大約 10 秒的額外延遲。作者指出，效能可以透過「預熱 (warming...」

Sources