エンジニアブログです。MLOps機械学習エンジニアの吉田です。性能を検証した話を書きましたが今回はその続編となります。Serverの検証を重ねた結果、推論サーバの性能を大幅に改善することができ、無事本番に導入することができました。この記事では本番導入までにどのような改善や検証を行ったのか書きたいと思います。はじめに背景バクラクでは請求書OCRなどの機械学習モデルを開発しており、リアルタイムで推論結果を返す必要があります。リリース以降問題なく稼働してきましたが、お客様の増加やユースケースの多様化に伴いよりスケーラブルなシステムや効率的な運用が求められるようになりました。具体的な課題としては以下のようなものがありました。上記の課題を解決するために、主に以下の3つの改善を行いました。よる推論レイテンシの改善TensorRTでは推論時の演算をFP16やINT8の低精度にすることができ、通常のFP32での推論と比較して推論速度やメモリ効率の大幅な向上が期待できます。デメリットとしてはモデルの推論結果が変わり、タスクによっては精度が悪化する可能性があります。TensorRTをFP16で変換したモデルの性能を以下の条件で検証しました。大きな劣化はみられなかったマルチモデルエンドポイントの活用SageMakerには単一のエンドポイントで複数の機械学習モデルをサービングすることができるマルチモデルエンドポイントという機能があり、エンドポイントを呼び出す際にターゲットモデルのパスをパラメータで指定することで、推論するモデルを切り替えることができます。画像引用元マルチモデルエンドポイントを活用し、複数モデルのエンドポイントを集約することでリソースの無駄なアイドルを減らすことができます。モデル毎にサーバを用意するのではなく、共通化したサーバを複数台並べることで特定モデルに対する突発的なスパイクリクエストへも対応しやすくなります。懸念点としては、リソースが不足した場合にモデルが動的にアンロードされる点でした。この場合、次回リクエスト時にモデルのロードが走ることで高レイテンシとなってしまうので負荷試験でリソースに余裕があることを確認しました。Serverに切り出し、前処理/後処理はいままで通りFastAPIで処理するようにアーキテクチャを変更しました。Serverはマルチモデルエンドポイントを活用することで、複数モデルでエンドポイントを共通化します。前処理/後処理を行うFastAPIサーバはGPUが不要となるのでCPUインスタンスを使うことでコストを下げることができます。workerを増やし、スループットを上げることが可能になります。FastAPIサーバは、推論対象のモデルを指定するパラメータの追加だけなので、リリース時はクライアントの実装は大きく変更することなく切り替えができます。最後に推論処理だけではなく、前処理/後処理も含めた全パイプラインでの新旧アーキテクチャでの性能と、サーバの台数を増やした場合にどの程度スケールするのか検証を行いました。Serverそれぞれ2台の構成で、2つのモデルをマルチモデルエンドポイントでデプロイしました。Serverは、本番リリース後の状況をみてチューニングすることを考えていたので前回の記事で検証していた動的バッチ処理は使いませんでした。(色の違いはモデルの違い)本番リリース以降、99パーセンタイルレイテンシの平均値で約55%、最大値で約80%減少させることができました。マルチモデルエンドポイントで懸念していたモデルのアンロードも発生せず、稀に発生していたタイムアウトもリリース以降無くなりました。リソースもかなり余裕があるのでしばらくはパフォーマンスについては悩まなくてよさそうで最高です!課題TensorRTを使うことで、今回のケースでは精度への影響は小さかったものの、推論結果が変わってしまうことや動かせるハードウェアが制限されてしまいます。本番とまったく同じ結果を得ようと思うと、開発環境でも本番と同じ環境を用意する必要があり、コストの増加や評価が難しくなるといった課題が残ります。機械学習エンジニアの上川です。LLM機械学習エンジニアの吉田です。機械学習チームのテックリードを務めております機械学習エンジニアの島越(@nt_4o54)です。機械学習エンジニアの吉田です。機械学習エンジニアの吉田です。機械学習エンジニアの吉田です。読者になるこのブログについてはてなブログをはじめよう!layerxさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。