1.3K Views
March 21, 25
スライド概要
2025/03/14に開催されたオフライン勉強会「DeNA Data/ML Engineering Night」の発表スライドです。
イベント概要: https://dena.connpass.com/event/339744/
DeNA が社会の技術向上に貢献するため、業務で得た知見を積極的に外部に発信する、DeNA 公式のアカウントです。DeNA エンジニアの登壇資料をお届けします。
TechCon 2025 AfterEvents March 14, 2025 Triton Inference ServerとTensorRT の導入による機械学習サービスの 性能とリソース使用効率の改善 株式会社ディー・エヌ・エー ソリューション本部データ統括部データ基盤部プラットフォームグループ 黄 英智 © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 1
自己紹介 黄英智(HarrisonEagle) ● ソリューション本部データ統括部データ基盤部プラット フォームグループ所属 ● 23新卒 ● SRE & MLOpsエンジニア ● 趣味: 旅行、筋トレ、ゴルフ、格闘技、読書(歴史関係) ● 普段はHarrisonと呼ばれていますが、ハンネの由来は「地面 師たち」と一ミリも関係ありません © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 2
目次 1 はじめに 2 機械学習サービスの運用で遭遇する課題 3 Triton Inference ServerとTensorRTを用いたサービスの改善 4 まとめ © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 3
はじめに © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 4
Pocochaについて © DeNA Co., Ltd. ● DeNAが開発・運営している ライブコミュニケーションアプリ ● 配信を行うライバーと、コメントや アイテムで応援するリスナーとの双 方向コミュニケーションが特長 ● 2017年に国内でサービス開始し、 現在でも成長中 TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 5
PocochaのAIによる審査効率化について ● ● © DeNA Co., Ltd. 人間の審査とAIによる検知を組み合わせた、Human-in-the-Loopを取り入れたシステム 配信内容やコメントの健全性の審査を、AIによってサポートしている TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 6
内製機械学習基盤Hekatoncheirについて ● 推論用API/システムの提供を 効率よく、かつ安定運用を 行うために開発された内製の 機械学習基盤 ● Pococha ではAI審査効率化 など、様々な機械学習を活用 したサービスがHekatoncheir を用いて運用されている AIによる価値提供 データサイエンティスト‧MLエンジニア 推論システム提供までのオペレーションの標準化‧⾃動化 ML推論基盤 Hekatoncheir Hekatoncheir の詳細については、DeNA AI Day || TechCon 2025 アーカイブ 「機械学習モデルの安定提供を加速させる社内基盤 Hekatoncheir」ご参照ください © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 7
内製機械学習基盤Hekatoncheirについて サービス 利用者 開発者 ● ● © DeNA Co., Ltd. GKEをベースに推論APIの実行基盤を構築 GKE標準の機能に加え、推論APIのデプロイに必要な要素をサポート TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 8
機械学習サービスの運用で遭遇する課題 © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 9
Pococha高リスク画像検知APIについて ● ● © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 配信のキャプチャ画像が 何らかの違反カテゴリの画像で あるかどうかをAIモデルを 駆使して予測するもの FastAPIで実装 10
課題1: 性能がボトルネックになっている ● 入力された画像のダウンロードから機械学習処理を行うための前処理、 そしてモデルによる推論処理からとレスポンス返却といった後処理まで 1つのサービス上で全て行われているため、1リクエストごとの処理の負荷が高い ● 最大同時接続数が少なく、API通信量が増加した場合はGKEのスケールアウトが 発生する © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 11
課題2:リソース使用効率が悪い Data Fetching ● 前/後処理と推論では CPUとGPUを多く使うが、 モノリシックな構成であるため リソース効率が悪い ● Podのリソース確保と GKEのオートスケーリングで 必要以上にリソース確保が生じる ため、大きくコストがかかる IO Bound Image/Audio Processing CPU Bound Feature Extraction Inference GPU Bound PostProcess © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 12
課題3: オートスケーリングが遅い ● GPUを使用して推論では、 以下の要因でスケールアウトと サーバー起動に時間がかかる ○ ○ ○ © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night GPU付きノードの確保 ■ GCP側のGPU枯渇により、20 分以上かかることもある CUDAを内包した巨大なイメージ の読み込み モデル読み込み & ウォームアップ 13
Triton Inference ServerとTensorRTを 用いたサービスの改善 © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 14
今回取り組んだ改善アプローチと得られた結果 課題\改善策 Triton Inference Server の導入 TensorRT の導入 性能面のボトルネック 推論処理を移譲し、サービス全体の モデル最適化により推論処理を3倍以上に高速 限界RPSが1̀.5倍以上改善 化 アーキテクチャを見直し、CPU Bound TensorRTモデルの採用により、モデル推論時 とGPU Boundの処理を分離したこと のCPUとメモリ使用量をそれぞれ50%以上改善 リソース使用効率が悪い で、必要なリソースは最低限に オートスケーリングが遅い 推論処理の分離によって、オートス ケーリングするAPIサーバーが軽量化 TensorRTモデルの採用により、GPUノードの オートスケーリングを回避 し、オートスケーリング時間が80%ほ ど削減 © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 15
Triton Inference Serverとは ● NVIDIAが提供するオープンソースの推論サーバ ● C++ベース ● PyTorch, TensorFlow, ONNX, TensorRTなどあらゆる機械学習 フレームワークやライブラリで作成したモデルを運用できる ● © DeNA Co., Ltd. 推論に特化された最適化機能も提供されている TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 16
Hekatoncheir Model Serving Platformとは ● 推論処理のみ行うマイクロ サービスをHekatoncheir上に デプロイするための仕組み ● 推論部分を抽象化 ● 共通の推論サーバーとして、 Triton Inference Serverを使用 TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 17 Model Serving Platform によって管理 © DeNA Co., Ltd.
Hekatoncheir Model Serving Platformとは 推論サーバーに必要なリソースをカスタムリソースでテンプレート化し、少 ない行数のコードでデプロイが可能。推論サーバーの管理はカスタムコント ローラーを内製することにより自動化 © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 18
Triton Inference Server導入後のPococha AI審査サービスのアーキテクチャ GPU-Boundの 処理に特化 ● 前処理・後処理 ○ ○ ○ (前後処理用) ● CPU-Boundの 処理に特化 © DeNA Co., Ltd. モデル推論部分 ○ ○ Model Serving Platform によって管理 ● TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night CPU処理が中心 FastAPIで処理 オートスケーリングし やすいよう軽量化 GPU処理が中心 Triton Inference Server での処理へ変更 ネットワーク部分 ○ Envoy Proxy を利用する ことでgRPCセッション を管理し、 常時接続によるPodの負 荷増加を抑制 19
Triton Inference Server導入前後のレイテンシー比較 Percentile 従来の構成 Triton Inference Server利用時 50%ile 430ms 350ms 95%ile 740ms 490ms 99%ile 960ms 740ms 推論部分のマイクロサービス化によるレイテンシー悪化は見られず、 改善前と比べて若干のレイテンシー改善が見られた © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 20
改善前のリソース使用率推移 オートスケーリングを停止し、1 Podに限界まで負荷かけ続ける 1 Podあたりのリソース要求: CPU: 6, Memory: 24GB, GPU: NVIDIA T4 x1 リソースを多めに確保しているが、CPUとGPUの使用量どちらも高止まりで、改善余地が少ない © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 21
Triton Inference Server導入後のリソース使用率推移 前後処理を行うFastAPIサーバーと推論サーバーを1台ずつ準備した状態で負荷試験を行った結果、 改善前と比べ限界RPSが1̀.5倍程に改善 前後処理APIサーバー (CPU: 4, Memory 8GiB) 推論サーバー (CPU: 4, Memory: 8GiB, GPU: NVIDIA T4 x1) 限界RPS時のリソース使用量が改善されたもののリソース要求を削減する余地が残り、 更に限界RPSが伸び悩んだため大幅な改善にはならず © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 22
さらに改善するには... GPUを使用する場合、NVIDIA公式ではTensorRTでモデルを最適化することが推奨されている © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 23
TensorRTとは ● 高性能な深層学習ライブラリ ○ ● 深層学習モデルの推論の高速化に特化している 以下によりモデルの軽量化と高速化を実現 ○ 重みの量子化 / レイヤーの融合 / カーネルのチューニング etc... ○ モデル軽量化により、メモリなどのリソース 使用量も削減可能 © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 24
TensorflowのモデルをTensorRTに変換 Pococha高リスク画像検知APIで運用されているTensorflowモデルを、ONNX経由で TensorRTモデルに変換する Tensorflow → ONNX: tf2onnxで変換 python -m tf2onnx.convert --saved-model {SAVED_MODEL_PATH} --output model.onnx --opset 13 ONNX → TensorRT: trtexecで変換 trtexec --onnx=model.onnx --explicitBatch --saveEngine=model.plan デフォルトはFP32形式に変換される、FP16とINT8形式にしたい場合は--fp16あるいは--int8を指定する © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 25
TensorflowモデルとTensorRTモデルのスループット比較 各モデルをそれぞれTriton Inference Serverに載せ、NVIDIA公式が出したTriton向け性能検証ツールで あるperf_analyzerで性能検証 TensorRTの場合、Tensorflowよりスループットが3倍以上改善している © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 26
TensorflowモデルとTensorRTモデルの推論時間比較 TensorRTの場合、推論に要した時間はTensorflowと比べ3倍以上改善している © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 27
TensorRTモデルの精度 ● © DeNA Co., Ltd. モデルをTensorRT形式に変換した際、推論精度に変化が発生 ○ TensorRT FP32形式 ■ 元のモデルと比べて、小数点4~5位以降に差分が発生 ■ 検証結果をもとに担当のデータサイエンティストとも議論し、 FP32形式での精度の方が許容できる範囲にあると判断 ⇒ 本番環境ではこちらを採用 ○ TensorRT FP16形式 ■ 元のモデルと比べて、小数点1~2位以降に差分が発生 TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 28
Triton Inference Server + TensorRT構成の性能とリソース使用効率 前後処理FastAPIサーバーと推論サーバーがそれぞれ1台の状態で、限界まで負荷をかけ続けた場合、改 善前と比べ限界RPSが2̀倍以上に改善 前後処理APIサーバー (CPU: 2, Memory 3GiB) 推論サーバー (CPU: 1, Memory: 1GiB, GPU: NVIDIA T4 x1) 前後処理APIをスケールアウトすることで、推論サーバー1台でも従来の4倍程の通信を耐えられることが わかり、リソース要求量を50%以上削っても十分運用できると判断し、本番導入へ © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 29
Triton Inference Server + TensorRT構成で本番運用した効果 ● サービスの性能が改善 ○ ● リソース使用効率が大幅に改善 ○ ○ ● オートスケーリングが比較的軽量な前処理・後処理の API だけで済むようになり、 従来 5mins 前後かかったスケールアウト処理が 30s ~ 1min 前後に減少 開発体験も一定改善 ○ © DeNA Co., Ltd. CPUリソースについては50%削減、メモリも80%削減したことでリソース必要量が減少 他サービスにおいても、同様にリソース効率改善がなされたことで全体的なGKEノード のスケールダウンによりコスト削減にも寄与する オートスケーリング効率が大きく改善 ○ ● 推論サーバーにおいて、低スペックなPod1つでも、従来と比較して4倍のトラフィック に耐えられるようになった FastAPI側の軽量化により、Pythonライブラリの依存関係の整理や コンテナイメージの メンテナンス効率が改善され、開発体験向上にもつながった TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 30
本番運用で遭遇した課題 サービス改善をリリース後 全体的に性能は改善されたが、FastAPI側で発生する95%ile以上のスパイクが、改善 前と比べて増加していた © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 31
Uvicorn vs Gunicorn Multiple Worker 処理する画像によって変わることも一因ではあるが、リソース要求削減により、各 Uvicornプロセスに当てるコアが1を下回り、高負荷時に不安定になりやすくなった API Pod Gunicorn Uvicorn Worker Uvicorn Worker Uvicorn Worker Uvicorn Worker API Pod Uvicorn API Pod Uvicorn API Pod Uvicorn API Pod Uvicorn 1つのPodにGunicornで複数のUvicorn Workerを動かすのではなく、Uvicornプロセスご とに1つのPodを割り当て、大きめなPodを複数の小さなPodに分ける構成に変更 上記の変更後、FastAPI側のスパイクが減少し、現在でも本番環境で概ね安定運用中 © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 32
まとめ © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 33
まとめ ● Pocochaでは、AIを用いて配信内容やコメントの健全性の審査を補完している ● モノリシックな機械学習サービスのモデル推論部分を Triton Inference Server に 分離することで、リソース使用効率とサーバー性能が一定向上する ● Triton Inference Server と同時にモデルを TensorRT 形式に変換することで リソース使用効率とモデル推論の性能が大きく改善できる ● Triton Inference Server と TensorRT を採用することによって Pococha 高リスク 画像検知 API に存在していた性能面と運用面の課題が改善できた ● Gunicorn の Worker は1つの Pod に集約せず、複数の Uvicorn Pod に分散させる ことで安定する © DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 34
おまけ: 推論サーバーのオートスケーリングを改善する ● © DeNA Co., Ltd. GPU付きノードのスケジューリングはGCPのリソース状況に依存するが、それ以 外の対策として下記が考えられる ○ 巨大なコンテナイメージのダウンロード高速化 ○ 大きなモデルのダウンロード高速化 ■ これらについては、GKE 1.30.1からGAとなった、セカンダリブート ディスクによるコンテナイメージのプリロードにより、サーバー起動 時コンテナイメージのプルとモデルのダウンロードを省ける TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 35
© DeNA Co., Ltd. TechCon 2025 AfterEvents / DeNA Data/ML Engineering Night 36