WEDでMLエンジニアやDSもしている園芸係です。普段は、社内の窓際と家のベランダでたくさんの植物を育てています。
あらまし
WEDでは、レシート買取りサービスONEを開発運用しています。
前回は、ONE でのレシート情報の抽出の際に使用する LLM モデルの作成についての記事でした。
今回は、それをどうやって推論を運用したのかについてです。
レシートからの情報抽出は1つのモデルで推論するのではなく、保守性の観点から次の2つのモデルで順次推論していく流れになっています。
- チェーン店、住所、電話番号などの情報抽出
- 商品名、個数、値段の集合の情報抽出
案
推論行うにあたって次のようなフレームワークの採用を検討しました。
A. FastAPI
- 推論用のフレームワークではないので推論処理は自分でプログラムを書く必要がある
- モデルのロードは柔軟に制御できる
- 推論のフローは柔軟に制御できる
- バッチ化も柔軟に制御できる
B. TorchServe
- 推論用のフレームワーク
- モデルのロードは柔軟に制御できる
- 推論のフローは柔軟に制御できる
- ダイナミック・バッチ化も柔軟に制御できる
- 推論のフローとダイナミック・バッチ化を同時に使えない！
C. MLFlow
- 機械学習のライフサイクルの統合環境
- 推論だけでなく学習も含めて MLFlow の作法に合わせる必要
検討
まず、MLFlowについてです。
MLFlowは機械学習のライフサイクルの統合環境で、その中に推論モジュールもあります。WEDではすでにデータ・ウェアハウスとして、BigQueryを使用しており、また推論環境とモデルの管理は、Docker Imageを考えていました。MLFlowを導入するとなると、色々なことができる分、学習コストが高く、やれることも縛られてしまう、ということからいったん見送りました。
GPUの運用コストは高く、できるだけ1推論にかかる時間を減らすことを目指しました。
特に、ONEのサービスでは、時間課金のクラウドサービスを使用していますが、1日の推論量が多くなる場合、高速化のあるなしでコストの差は大きく変わってきてしまいます。
GPUの特性上、なるべく推論をまとめるバッチ化をした方が、1推論にかかる時間を減らすことはできます。
また、店舗名や住所、電話番号を抽出する処理と、商品名・個数・値段をを抽出する処理も、同一のレシートの文字列から行うので、これも同じフローの中で順次行なった方が、効率が良くなると考えました。
当初は、TorchServe での、バッチ化とフロー化を考えていたのですが、どうしてもバッチ化とフロー化が同時にうまく動かせず、さらに FastAPI で同等の機能を実装したらあっさり動いてしまった、というのもあり、今は FastAPI 上で動かしています。
デプロイに関しては、こちらの記事VertexAI Online Predectionの運用をご覧ください。
結果
1日100万弱の推論を安定して実行できています。
バッチするために、推論すべきデータをいったん溜めてから処理するようにしたのですが、このことにより、急に推論すべきデータが増えても安定して動くようになり、この点でも「バッチ化」はやって良かったなと思っています。
今後
推論機能を実装している間に、
D. NVIDIA Triton Inference Server
もあることがわかったのですが、
まだ未調査のため、分かり次第また更新したく思います。
Discussion