Vertex AI Online Predictionを使用した ONEのレシート情報抽出モデルのサービング

導入背景

従来のレシート情報の抽出する方法はルールベース(正規表現等)によるレシート情報を抽出を行っていたが、社内で独自に作成&チューニングを行ったLLMのモデルを使用したレシート情報抽出モデルをデプロイし、APIとして使用できるものを探していました。

詳しくはこちら: 国内最高精度のレシートデータを。独自OCR技術の誕生秘話

• Databrick Model Serving
• Amazon SageMaker

移行のスケジュールの観点やONEのサービス自体がGCPを元に構築されており、デプロイのフローやTerraformでの環境構築の環境が整っていたので採用しました。

改善したかった課題はどれくらい解決されたか

• ルールベース(正規表現等)での抽出からLLMのモデルを使用した抽出に変えることができ、OCRからレシート情報の抽出を全て置き換えることができた。

詳しくはこちら: LLMを用いたレシート情報抽出を本番導入した話

どのような成果が得られたか

• OCRの精度も向上し、より良いレシートデータを取得することができるようになった。
• デプロイの管理やモデルの切り替えが容易にできる。

GPUを使用するとスケーリングまで時間がかかる

今回はVertex AIのOnline PredictionにLLMのモデルをデプロイしています。GPUを使用しているのでレプリカ1台に対して1台GPUを付けてデプロイを行っています。レシートのOCRが増えるとモデルへのアクセスも増えるのでオートスケーリングの設定をしていますが、GPUを使用しているとスケールするまで10~20分ほどかかってしまします。

レシート買取が始まる時間だとOCRと推論のリクエストが増えるので、事前にAPIを使用してレプリカの数を増やして負荷に対応しています。

アクセス負荷が高まると5XX系のエラーが出る

負荷が高まってくると5XX系のエラーを返すことがあり、レシート情報の抽出が失敗してしまう時があります。なのでサーバー側でVertex AI側にリクエストを送る際にはリトライの設定をして、決められた回数リトライをするように作成しています。

GPUの割り当ての確保

GCPのコンソールから割り当てから確認できますがCustom model serving Nvidia T4 GPUs per regionの値を事前に申請を増やしておかないとスケーリングが失敗してしまいます。
デフォルトの値が14台だったので14台より多く使用する場合は割り当ての申請を事前に行う必要があります。

詳しくはこちら: Vertex AI Online Predictionを運用してみての話

手軽にモデルをデプロイできる点がいい点なのでまずは試しにデプロイをしてみることをお勧めします。使用するモデルや環境、GPUでエラーやデプロイの仕方も変わってくると思います。

まだAPIとしては存在するがUI側が追いついていない点やオートスケーリング等の設定がより柔軟に行えるようになることを期待しています。