はじめに
こんにちは、研究開発部の石井です。
いきなり本題ですが、TorchServe をご存知でしょうか。
PyTorch 公式のリポジトリに所属する、PyTorch のモデルを本番環境でサービングするためのライブラリです。
この TorchServe ですが 2025 年 3 月 1 日に Limited Maintenance モードになりました。
記載によると、リポジトリは残すがバグ修正やセキュリティパッチの予定はないとのことです。
弊社では PyTorch で作成したモデルの推論ライブラリに TorchServe を採用しているシステムがあります。
現段階で大きな問題があるわけではありませんが、今後脆弱性が報告されるリスクがあること、機能追加の予定がないことから長期的な利用は難しくなっていくと判断し、移行の検討を開始しました。
本エントリーではこの移行検討の過程と結果を紹介します。
なお、TorchServe に対して特別強い不満はないため、同程度の機能・パフォーマンスを持つ移行先ライブラリの目処を付けることが目的となります。
ライブラリ選定の観点
まずは移行するライブラリの候補を選定することから開始しました。
現状、下記の構成で TorchServe を運用しています。
- HTTP 通信を利用する。（gRPC 通信を利用しない。）
- 動的バッチ処理を利用しない。
- 単一の GPU を利用する。
- 複数のワーカーを利用する。
- 複数のモデルをデプロイする。
- モデルの形式は transformers の safetensors 形式である。（厳密には推論のためにシリアライズした mar（Model Archive）形式を用いている。）
従って、最低限この要件を満たす必要があります。
要件を満たすライブラリの候補をいくつか選定したうえで、推論ライブラリとしてのパフォーマンスを調査することにしました。
選定したライブラリ
TorchServe から移行する候補のライブラリとして、下記 4 つを選定しました。
- BentoML
- LitServe
- Triton Inference Server
- FastAPI + Uvicorn
それぞれについて簡単に紹介します。
BentoML（GitHub Star 数 7.5 K）
BentoML は AI アプリケーションやモデル推論に最適化されたオンライン サービング用の Python ライブラリです。主な特徴は以下の通りです。
- 簡単な API 構築：数行のコードで ML モデルを REST API サーバーに変換できます
- Docker 対応：依存関係の管理が簡単で、自動的に Docker イメージを生成します
- 高性能：動的バッチ処理やモデル並列化など、CPU/GPU を最大限に活用する機能を備えています
- カスタマイズ性：独自の API やタスクキューを実装でき、あらゆる ML フレームワークに対応します
- 本番環境対応：ローカルでの開発・デバッグから、Docker や BentoCloud を使った本番環境へのデプロイまでシームレスに行えます
（README.md より説明を抜粋・翻訳）
正直 DeepResearch で初期調査をしていて初めて知ったのですが、スター数や機能面としては申し分なかったため比較対象として選定しました。
LitServe（GitHub Star 数 3.0 K）
LitServe は FastAPI をベースにした使いやすく柔軟な AI モデルサービングエンジンです。バッチ処理、ストリーミング、GPU の自動スケーリングなどの機能を備えており、モデルごとに FastAPI サーバーを再構築する必要がありません。AI に特化したマルチワーカー処理により、通常の FastAPI と比べて少なくとも 2 倍の処理速度を実現しています。
（README.md より説明を抜粋・翻訳）
深層学習モデルのフレームワークとして有名な lightning が提供している2024 年頃に登場した比較的新しいライブラリです。普段 lightning を学習フレームワークとして利用していて以前から気になっていたこともあり、比較対象として選定しました。
Triton Inference Server（GitHub Star 数 8.9K）
Triton Inference Server は、AIの推論を効率化するオープンソースのサーバーソフトウェアです。TensorRT、TensorFlow、PyTorch、ONNX、OpenVINO、Python、RAPIDS FILなど、多様な機械学習フレームワークのモデルをサポートしています。クラウド、データセンター、エッジデバイスなど、様々な環境でNVIDIA GPU、x86/ARM CPU、AWS Inferentiaを使用した推論が可能です。リアルタイム処理、バッチ処理、アンサンブル、音声/動画ストリーミングなど、多様なクエリタイプに対して最適化されたパフォーマンスを提供します。このソフトウェアは、AIの開発からデプロイメントまでを効率化するNVIDIA AI Enterpriseの一部として提供されています。
（README.md より説明を抜粋・翻訳）
NVIDIA が提供するサービングライブラリであり、様々なモデル・プラットフォームをサポートしています。過去の選定時は Triton Inference Server と TorchServe で悩み、実装の容易さ・公式のサポートである点から TorchServe を選定しました。
機能の豊富さ、実績、最適化の余地といった点から見ても TorchServe を採用しないのであれば本命である、と個人的には考えており選定しました。
後述しますが今回は ONNX や TensorRT といった推論に最適化されたモデル形式・バックエンドではなく、transformers の PretrainedModel を save_pretrained した safetensors 形式のモデルを Python Bankend で起動させて検証を行います。
FastAPI + Uvicorn（GitHub Star 数 82.1K）
FastAPIは、Pythonの型ヒントを活用したモダンな高性能Webフレームワークです。
主な特徴は下記のとおりです。
- 高速：NodeJSやGoと同等の高いパフォーマンスを実現
- 開発効率：開発速度が200-300%向上
- 品質向上：人的ミスを40%削減
- 使いやすさ：直感的なエディタサポートとデバッグ機能
- シンプル：学習が容易で、コードの重複を最小限に抑制
- 堅牢性：本番環境に対応した自動ドキュメント生成機能付き
- 標準準拠：OpenAPIやJSON Schemaなどの標準規格に完全対応
（README.md より説明を抜粋・翻訳）
機械学習用の推論ライブラリではないのでパフォーマンス面の期待を持っているわけではないですが、ベンチマークとして比較対象に選定しています。マルチプロセスワーカーとして Gunicorn を利用することが一般的でしたが最近 Uvicorn がそれなりにマルチプロセスに対応したとのことで FastAPI + Uvicorn を選定しました。
TorchServe（GitHub Star 数 4.3K）
TorchServe は PyTorch モデルの本番環境でのサービング・スケーリングを実現する柔軟で使いやすいツールです。
（README.md より説明を抜粋・翻訳）
最後に念の為、TorchServe についても記載しておきます。 移行先の候補ではありませんが、性能のベースラインとして比較対象に加えています。
負荷試験
続いて、それぞれのライブラリのパフォーマンスを評価するために負荷試験を行いました。
なお、負荷試験の実行にあたり、下記の通り条件を設定しました。
- サーバー（負荷をかけられる側）
- Dynamic Batching を使用しない。
- 利用するモデルは単一とし、ワーカー数は 4 とする。
- タイムアウトを指定しない。
- AWS の EC2（g6.xlarge）にてサーバーを起動する。
- モデルは推論コード上で safetensors を読み込む（
transformers.PretrainedModel.from_pretrainedメソッドを呼ぶ）。
- クライアント（負荷をかける側）
- 負荷試験ツールとして Locust を利用する。
- 待ち時間は 0 秒とする。
- タイムアウトを指定しない。
- AWS の EC2（サーバーとは異なるインスタンス）にて負荷をかける。
上記の条件で、下記 3 つのテストシナリオを実行し、結果を比較しました。
- テスト 1（同時実行数 1、実行時間 5 分）
- テスト 2（同時実行数 10、実行時間 5 分）
- テスト 3（同時実行数 100、実行時間 5 分）
テスト 1（同時実行数 1、実行時間 5 分）
直列でリクエストを行い、各ライブラリの基本性能を確認しました。
結果
各ライブラリの結果を比較した表と図を下記に記載します。
| ライブラリ | 処理件数 [うちエラー件数] | rps (requests per second) | latency 中央値(ms) | latency 平均値(ms) | latency 99%(ms) |
|---|---|---|---|---|---|
| TorchServe | 692件 [0 件] | 2.31 rps | 480 | 432.3425077 | 570 |
| Triton | 667件 [0 件] | 2.23 rps | 500 | 445.3257012 | 580 |
| LitServe | 644件 [0 件] | 2.15 rps | 520 | 464.2694086 | 610 |
| FastAPI | 642件 [0 件] | 2.15 rps | 520 | 465.6028064 | 610 |
| BentoML | 640件 [0 件] | 2.14 rps | 510 | 467.2389855 | 600 |
また、CPU 使用率、メモリ使用率、GPU 使用率、GPU メモリ使用率は下記のとおりです。
考察
TorchServeが最も高いスループット（2.31 rps）、レイテンシ中央値（480 ms）を記録しました。 とはいえすべてのライブラリのレイテンシ中央値が 480-520ms の範囲内に収まっています。 CPU 使用率、GPU 使用率は各ライブラリ毎にほとんど差はありませんでした。 メモリ使用率はライブラリによる差が比較的大きく FastAPI が 50% 程度と小さいです。 GPU メモリ使用率はやや見づらいですが TorchServe、Triton が比較的安定しているように見えます。
全体的に細かな差分であり、単一ユーザーでの利用シナリオにおいてはどのライブラリを選択しても大きな性能差は生じないと考えられます。
テスト 2（同時実行数 10、実行時間 5 分）
続いて、同時実行数を 1 から 10 に増やし、複数のワーカーが効率的にリクエストを処理できるかを確認します。
結果
各ライブラリの結果を比較した表と図を下記に記載します。
| ライブラリ | 処理件数 [うちエラー件数] | rps (requests per second) | latency 中央値(ms) | latency 平均値(ms) | latency 99%(ms) |
|---|---|---|---|---|---|
| TorchServe | 1212件 [0 件] | 4.05 rps | 2500 | 2423.171599 | 3200 |
| Triton | 1192件 [0 件] | 3.98 rps | 2500 | 2458.41932 | 3300 |
| LitServe | 1171件 [0 件] | 3.91 rps | 2600 | 2506.244648 | 3400 |
| FastAPI | 1163件 [0 件] | 3.89 rps | 2500 | 2522.054921 | 5700 |
| BentoML | 1156件 [0 件] | 3.86 rps | 2500 | 2534.838395 | 5000 |
また、CPU 使用率、メモリ使用率、GPU 使用率、GPU メモリ使用率は下記のとおりです。
考察
同時実行数を 10 にしたところ rps は全体的に向上し、2.1 ~ 2.3 → 3.8 ~ 4.1 程度になりました。
サーバーのワーカー数は 4 で、クライアントの同時実行数は 4 以上である（サーバーのワーカーは全て使われる）ため、理論上は 4 倍の rps が出る可能性がありますが、1.7 倍程度のパフォーマンス向上に留まっています。
ここで CPU、GPU の利用率を見ると全てのライブラリが 100% に張り付いています。
従って、このシナリオにおいては CPU あるいは GPU の使用率がボトルネックになっている可能性があります。
レイテンシの中央値は 480 ~ 520ms → 2500 ~ 2600ms と大きく増加しました。サーバーのワーカー数（4）よりも同時実行数（10）が多いため、リクエスト待ちの時間が生じている事が分かります。
FastAPI、BentoML の 99% タイルレイテンシは 5000ms 以上となっており、一部のリクエストに対してはレイテンシが悪化することがわかりました。
対する TorchServe、Triton、LitServe の 99% タイルレイテンシは 3200 ~ 3400ms で中央値とのずれも 800ms 程度に収まっており、全てのリクエストに対して安定したレイテンシと言えそうです。
GPU メモリの使用率は同時実行数が 1 のときよりもライブラリごとの差が少し大きくなり、Triton と TorchServe が比較的小さい値に収まっていることが見て取れます。
なお、テスト 1 と同様に rps が最も良かったのは TorchServe でした。
テスト 3（同時実行数 100、実行時間 5 分）
最後に、同時実行数を大きく増やした場合にエラーを出さずにレスポンスを返し切ることができるかを確認します。
結果
各ライブラリの結果を比較した表と図を下記に記載します。
| ライブラリ | 処理件数 [うちエラー件数] | rps (requests per second) | latency 中央値(ms) | latency 平均値(ms) | latency 99%(ms) |
|---|---|---|---|---|---|
| TorchServe | 1213件 [0 件] | 4.05 rps | 24000 | 19597.59544 | 26000 |
| Triton | 1202件 [0 件] | 4.01 rps | 24000 | 19737.60099 | 26000 |
| LitServe | 1147件 [0 件] | 3.83 rps | 26000 | 20685.97744 | 28000 |
| FastAPI | 1318件 [160 件] | 4.41 rps | 18000 | 18077.54168 | 48000 |
| BentoML | 1157件 [0 件] | 3.87 rps | 23000 | 20376.18898 | 42000 |
また、CPU 使用率、メモリ使用率、GPU 使用率、GPU メモリ使用率は下記のとおりです。
考察
同時実行数を 100 に増やした場合でも rps はほとんど変化がありませんでした。
例外的に FastAPI の rps が非常に良くなっていますが 160 件のエラーが発生しています。従って、見かけ上の rps は向上していますが、正常なレスポンスに対する rps はほぼ変わりません。
TrochServe, Triton, LitServe は 99% タイルレイテンシも 26000 ~ 28000 ms と比較的安定していました。
同時実行数が 10 の場合と同様に FastAPI と BentoML は 99% タイルレイテンシが中央値を大きく超えており、一部のリクエストで大きな遅延が発生しています。
GPU メモリの使用率は同時実行数が 10 のときと同傾向で Triton と TorchServe が比較的小さい値に収まっていることが見て取れます。
なお、テスト 1、テスト 2 と同様に rps が最も良かったのは TorchServe でした。
負荷試験のまとめ
同時実行数を 1 → 10 → 100 と増やして負荷をかけた場合のそれぞれのライブラリのパフォーマンスを比較しました。
全てのテストにおいて TorchServe のパフォーマンスが最も良く、Triton Inference Server、LitServe が続く結果となりました。
BentoML と FastAPI は 99% タイルレイテンシの悪化が目立ちました。また、FastAPI は一部のリクエストを捌ききれずにエラーレスポンスを返しました。
終わりに
TorchServe からの移行先ライブラリを決めるために、機能面で充足するライブラリを 4 つ選定し、 3 つのシナリオで負荷試験を行いました。
負荷試験の結果は全て TorchServe が最も良かったものの、Triton Inference Server と LitServe も同程度のパフォーマンスを発揮することが分かりました。
一方、BentoML と FastAPI は、高負荷時のレイテンシ悪化やエラー発生といった課題がありました。移行先としては Triton Inference Server あるいは LitServe が有力候補となりそうです。
ただし、Triton Inference Server と LitServe の性能はそこまで大きなものではなかったため、どちらに移行するかは判断が難しい結果となりました。
今後はより細かいシナリオでの調査が必要です。 例えば、今回の検証では下記の観点に関する確認は不十分でした。
- Triton Inference Server のバックエンドを調整していないため、パフォーマンスが不十分な可能性がある。
- TorchServe のみ必須要件とはいえシリアライズされた mar 形式を採用しているため、ややフェアな比較になっていない可能性がある。
- 長時間にわたる負荷をかけるテスト（soak test）を実施していないため、メモリリークに関する課題が残存している可能性がある。
- AWS の EC2 上で負荷テストを実施したため、実環境のパフォーマンスを完全に反映していない可能性がある。
また、推論のパフォーマンスはサービングライブラリだけに依存するわけではありません。例えば、計算グラフの最適化・量子化による高速化も考えられます。
パフォーマンスの要件を満たしていれば、必要以上に高速なライブラリを選定する動機が弱くなることもあります。このような状況であれば、パフォーマンスよりも下記のような継続的に価値を出すための観点の重要度が高まります。
- デプロイ、ロギング、モニタリングの容易さ
- コミュニティーの活発さ
- 将来の仕様変更に追従可能な拡張性
これらの要素を総合的に評価した上で、最終的な移行先を決定していきたいと思います。
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途・新卒の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
