Google Cloud上のサーバーレストランスフォーマーパイプラインへの私の旅

'Google Cloud上のサーバーレストランスフォーマーパイプラインへの私の旅' can be condensed to 'My journey to the serverless Transformer pipeline on Google Cloud.'

コミュニティメンバーのマクサンス・ドミニシによるゲストブログ投稿

この記事では、Google Cloudにtransformers感情分析パイプラインを展開するまでの道のりについて説明します。まず、transformersの簡単な紹介から始め、実装の技術的な部分に移ります。最後に、この実装をまとめ、私たちが達成したことについてレビューします。

目標

Discordに残された顧客のレビューがポジティブかネガティブかを自動的に検出するマイクロサービスを作成したかったです。これにより、コメントを適切に処理し、顧客の体験を向上させることができます。たとえば、レビューがネガティブな場合、顧客に連絡し、サービスの品質の低さを謝罪し、サポートチームができるだけ早く連絡し、問題を修正するためにサポートすることができる機能を作成できます。1か月あたり2,000件以上のリクエストは予定していないため、時間と拡張性に関してはパフォーマンスの制約を課しませんでした。

Transformersライブラリ

最初に.h5ファイルをダウンロードしたとき、少し混乱しました。このファイルはtensorflow.keras.models.load_modelと互換性があると思っていましたが、実際にはそうではありませんでした。数分の調査の後、ファイルがケラスモデルではなく重みのチェックポイントであることがわかりました。その後、Hugging Faceが提供するAPIを試して、彼らが提供するパイプライン機能についてもう少し調べました。APIおよびパイプラインの結果が素晴らしかったため、自分自身のサーバーでモデルをパイプラインを通じて提供することができると判断しました。

以下は、TransformersのGitHubページの公式の例です。

• パートナーシップ：Amazon SageMakerとHugging Face
• 分散トレーニング：🤗 TransformersとAmazon SageMakerを使用して、要約のためにBART/T5をトレーニングする
• Amazon SageMakerを使用して、Hugging Faceモデルを簡単にデプロイできます

from transformers import pipeline

# 感情分析のためのパイプラインを割り当てる
classifier = pipeline('sentiment-analysis')
classifier('We are very happy to include pipeline into the transformers repository.')
[{'label': 'POSITIVE', 'score': 0.9978193640708923}]

TransformersをGoogle Cloudに展開する

私の個人組織で使用しているクラウド環境としてGCPを選びました。

ステップ1 – 調査

flaskのようなAPIサービスを使用してtransformersモデルを提供できることをすでに知っていました。Google Cloud AIのドキュメントを検索して、TensorflowモデルをホストするためのサービスであるAI-Platform Predictionを見つけました。また、App EngineとCloud Runも見つけましたが、App Engineのメモリ使用量について心配で、Dockerにあまり馴染みがありませんでした。

ステップ2 – AI-Platform Predictionでテスト

モデルが「純粋なTensorFlow」の保存済みモデルではなくチェックポイントであるため、このページの例が機能しないことに気づきました。そこから、モデルを処理する代わりにpipelineをロードできるようにするカスタムコードを記述できることがわかりました。また、顧客のニーズに合わせてデータの事前処理や事後処理を行うために将来有用な前処理および後処理アクションを定義できることも学びました。Googleのガイドに従いましたが、サービスがまだベータ版であり、すべてが安定していないため、問題が発生しました。この問題についての詳細はこちらをご覧ください。

ステップ3 – App Engineでテスト

私はApp Engineに移行しましたが、TensorFlowのインストールに関する問題が発生しました。システムの依存ファイルが不足していたためです。その後、PyTorchを試しましたが、F4_1Gインスタンスでは2つ以上のリクエストを処理できず、パフォーマンス的にはあまり良くありませんでした。

ステップ4 – Cloud Runでテスト

最後に、Cloud RunにDockerイメージを使用して移行しました。これがどのように機能するかのアイデアを得るために、このガイドに従いました。Cloud Runでは、PyTorchを使用して予測を実行するためにより高いメモリとより多くのvCPUを設定できました。PyTorchの方がモデルの読み込みが速いようですので、TensorFlowは使用せずにしました。

サーバーレスパイプラインの実装

最終的なソリューションは、4つの異なるコンポーネントで構成されています：

• main.py – パイプラインへのリクエストを処理する
• Dockerfile – Cloud Runにデプロイされるイメージを作成するために使用されます。
• pytorch_model.bin、config.json、vocab.txt を含むModelフォルダ
  • モデル：DistilBERTベースの小文字のSST-2を学習済みにしたもの
  • モデルフォルダをダウンロードするには、ボタンの指示に従ってください。
  • rust_model.otやtf_model.h5は不要です。PyTorchを使用するためです。
• requirement.txt – 依存関係のインストールに使用します

main.pyの内容は非常にシンプルです。アイデアは、2つのフィールドを含むGETリクエストを受け取ることです。最初は解析する必要のあるレビュー、2番目はサービスを「保護」するためのAPIキーです。2番目のパラメータはオプションですが、Cloud RunのoAuth2の設定を回避するために使用しました。これらの引数が提供されると、モデルdistilbert-base-uncased-finetuned-sst-2-englishに基づいて構築されたパイプラインをロードします。最後に、最も適切なマッチがクライアントに返されます。

import os
from flask import Flask, jsonify, request
from transformers import pipeline

app = Flask(__name__)

model_path = "./model"

@app.route('/')
def classify_review():
    review = request.args.get('review')
    api_key = request.args.get('api_key')
    if review is None or api_key != "MyCustomerApiKey":
        return jsonify(code=403, message="bad request")
    classify = pipeline("sentiment-analysis", model=model_path, tokenizer=model_path)
    return classify("that was great")[0]


if __name__ == '__main__':
    # これはローカルでのみ実行されます。Google Cloud Runにデプロイする場合は、Gunicornなどのウェブサーバープロセスでアプリを提供します。
    app.run(debug=False, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))

次に、サービスのDockerイメージを作成するために使用されるDockerfileです。サービスがpython:3.7で実行されること、および必要な要件をインストールする必要があることを指定しています。そして、gunicornを使用してポート5000でプロセスを処理します。

# Python37を使用する
FROM python:3.7
# Knativeログに文とログメッセージをすぐに表示できるようにする
ENV PYTHONUNBUFFERED True
# requirements.txtをdockerイメージにコピーしてパッケージをインストールする
COPY requirements.txt /
RUN pip install -r requirements.txt
# WORKDIRをフォルダに設定する
COPY . /app
# ポート5000を公開する
EXPOSE 5000
ENV PORT 5000
WORKDIR /app
# エントリーポイントとしてgunicornを使用する
CMD exec gunicorn --bind :$PORT main:app --workers 1 --threads 1 --timeout 0

重要な点として、--workers 1 --threads 1という引数があることに注意してください。これは、1つのワーカー（= 1つのプロセス）でアプリを実行し、単一のスレッドで処理することを意味します。これは、請求額を増やす可能性があるため、同時に2つのリクエストを受けると処理に時間がかかる可能性があるためです。その後、モデルをパイプラインに読み込むために必要なメモリ使用量のために1つのスレッドに制限を設けました。4つのスレッドを使用している場合、4 Gb / 4 = 1 Gbしかフルプロセスを実行するためのメモリがなく、メモリエラーが発生します。

最後に、requirement.txtファイルです。

Flask==1.1.2
torch===1.7.1
transformers~=4.2.0
gunicorn>=20.0.0

デプロイ手順

最初に、Google Cloud上でプロジェクトを持ち、課金を有効化し、gcloud CLIをインストールするなどの要件を満たす必要があります。詳細については、Googleのガイド「開始する前に」を参照してください。

次に、適切なプロジェクトを選択して（PROJECT-IDを置き換える）、ai-customer-reviewなどのインスタンス名を設定して、DockerイメージをビルドしてCloud Runにデプロイする必要があります。デプロイに関する詳細情報については、Googleのガイド「デプロイ」を参照してください。

gcloud builds submit --tag gcr.io/PROJECT-ID/ai-customer-review
gcloud run deploy --image gcr.io/PROJECT-ID/ai-customer-review --platform managed

数分後、Cloud Runインスタンスに割り当てられたメモリを256 MBから4 GBにアップグレードする必要があります。そのためには、プロジェクトのCloud Runコンソールに移動してください。

そこでインスタンスを見つけ、クリックしてください。

その後、画面の上部に「編集と新しいリビジョンのデプロイ」という青いボタンが表示されますので、クリックしてください。すると、多くの設定フィールドが表示されます。一番下には「容量」というセクションがあり、メモリを指定することができます。

パフォーマンス

リクエストの処理には、リクエストを送信してからモデルをパイプラインにロードし、予測するまでの時間は5秒以下かかります。コールドスタートにはさらに10秒程度かかることがあります。

モデルをウォーミングすることで、リクエストの処理性能を向上させることができます。つまり、各リクエストごとではなく、起動時にロードすることで、時間とメモリの使用量を節約できます。

コスト

Googleの価格シミュレータを使用して、Cloud Runインスタンスの構成に基づいたコストをシミュレートしました。

私のマイクロサービスでは、月間1,000件のリクエストを予定していますが、楽観的には500件ほどです。そのため、マイクロサービスの設計時には上限として2,000件を考慮しました。リクエスト数が少ないため、スケーラビリティについてはあまり気にしていませんが、請求額が増える場合には再考するかもしれません。

ただし、ストレージにはビルドイメージごとにギガバイトあたり約€0.10の料金がかかります。クラウドにすべてのバージョンを保持しない場合は問題ありませんが、私のバージョンは1 GBをわずかに上回っています（PyTorchが700 MB、モデルが250 MB）。

結論

Transformersの感情分析パイプラインを使用することで、かなりの時間を節約することができました。モデルのトレーニング/微調整を行う代わりに、すでに本番で使用できるモデルを見つけてデプロイを開始することができました。将来的には微調整するかもしれませんが、私のテストでは既に精度が素晴らしいことが示されています！「純粋なTensorFlow」モデル、または少なくともTransformersの依存関係なしでTensorFlowでロードできる方法があると素晴らしいです。また、Liteバージョンがあると便利です。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!