モデルカスケードを使った効率的な推論サービング
モデルカスケードを利用して機械学習の予測を最適化するシステム。
― 1 分で読む
機械学習(ML)モデルがさまざまな業界での利用が増えている中、これらのモデルが作る予測を効率的に処理できるシステムの必要性が高まってる。でも、そういうシステムを作るのは簡単じゃない。主に2つの課題があるからだ:モデルを動かすための高コストと、予測リクエストが不規則であること。
推論サービングの課題
最初の課題は、MLモデルを使って予測を行う際の計算コスト。中には正確な結果を出すのに相当なコンピュータ資源が必要なモデルもある。次の課題として、多くのアプリケーションではリクエストの急激な増加が見られる。この変動のおかげで、いつどれだけのハードウェアを割り当てればいいのか分からない。
これらの課題に対処するための有望なアプローチのひとつに、モデルカスケードを使う方法がある。カスケードを使うと、作業量と精度のトレードオフをうまくバランスできる。カスケードの中で、単純で速いモデルが簡単なタスクを処理し、より複雑なモデルが難しい問題を扱うように組織することができる。この構成によって、全体的な計算負荷を減らしながら、良好な精度を維持できる。
モデルカスケードの説明
モデルカスケードでは、データはまず安価なモデルを通る。この初期モデルが予測に自信がある場合、その結果が最終出力として使われる。もし初期モデルが不確かな場合は、データがより正確で資源集約型のモデルに送られる。このシステムのおかげで、大多数の予測が迅速に低コストのモデルで行われ、複雑なケースでは高度なモデルを活用できる。
でも、モデルカスケードは実際のサービングシステムでは広く実装されていない。主な理由は、いくつかの課題があるからだ。一つ大きな壁は、システム負荷が変わる中で確実性のしきい値を動的に調整する必要があること。さらに、モデルを効率よく利用可能なハードウェアに割り当てる必要があり、リクエスト処理を最適化するためにさまざまなスケジューリング手法を使わなきゃいけない。
推論サービングシステムでモデルカスケードを実装するのは、作業負荷の変化に適応すること、モデルをハードウェアに割り当てること、推論をスケジューリングすること、リクエストをバッチ処理することなど、いくつかの側面を最適化することを含む。それぞれの要素が、効果的に管理するために慎重な考慮が必要な複雑な問題に寄与してる。
提案された解決策
効率的な推論サービングソリューションを提供するために、オフラインとオンラインの2つの主要なフェーズで動作するシステムが設計された。オフラインフェーズでは、リアルタイムで予測を処理するための計画を事前に計算する。この計画は「ギアプラン」と呼ばれ、利用可能なハードウェアや扱うことが予想されるクエリの種類などの要因を考慮する。
オンラインフェーズが始まると、システムはギアプランを活用して、リクエストに最小遅延で適応できる。ギアプランを使うことで、現在の作業負荷に基づいて操作モードを切り替え、パフォーマンスとリソースの利用を最適化することができる。
ユーザー入力
ユーザーは、いくつかの主要な入力を提供することでシステムをカスタマイズできる:
- カスケードを形成する訓練済みモデルの選択。
- モデルカスケードのパフォーマンスを評価するためのラベル付きデータサンプル。
- 利用可能なハードウェアリソースに関する情報、例えばGPUの数。
さらに、ユーザーはサービスレベル目標(SLO)を定義して、遅延を最小限にするか精度を最大化するかなど、特定のパフォーマンス要件を設定できる。
システムの動作
ユーザーがデータを入力すると、システムは必要に応じて異なるカスケードの間で切り替えることで予測を最適化する。異なるカスケードは処理時間が異なるため、システムはピーク時に高速なモデルを使って高いクエリ負荷に適応できる。逆に、負荷が減ると、より正確なモデルを使って質の高い出力を保証することができる。
でも、このシステムを最適化するのは簡単じゃない。モデルカスケードのパフォーマンスは、モデル自身だけでなく、利用可能なGPUの間での割り当て方にも影響される。それぞれのGPUにはメモリの制限があるため、モデルを複製するプロセスが複雑になる。
通常のサービングシステムでは、サンプルをまとめて一緒にモデルに送ることが一般的だ。バッチサイズを大きくすることでスループットが向上し、ハードウェアをよりよく活用できるが、十分なサンプルが集まるまで待たなきゃいけない。システムは、バッチの長さと全体のシステムパフォーマンスの両方を最適化するためのバランスを見つけなきゃならない。
これらの複雑さを処理するために、システムは意思決定の大部分をオフライン計画フェーズにシフトさせる。この間に、ギアプランを作成してシステムが稼働中に効率的に予測を提供する方法を指示する。この構造により、システムは大きなオーバーヘッドをかけずに迅速にほぼ最適な選択を行える。
ギアプランニング
ギアプランを考えるプロセスは、課題をいくつかのシンプルで管理しやすい部分に分解する:
- カスケードの構築:このステップでは、どのモデルがカスケードを構成するかを特定し、彼らの精度とパフォーマンスを評価する。
- 作業負荷に基づくカスケードの選択:異なるカスケードを様々なリクエストの範囲に割り当て、負荷が重い場合はより効率的なカスケードを呼び出す。
- ハードウェアへのモデルのマッピング:この部分では、利用可能なGPUの間でモデルを最適に分配する方法を決定し、メモリ制限や効率的な利用のニーズを考慮する。
- バッチサイズの決定:最後に、システムは予想されるクエリ負荷に基づいて各モデルレプリカに対する理想的なバッチサイズを決定する。
これらのサブ問題のそれぞれが、効果的に内部の複雑さを解決するために慎重な調整と最適化を必要とする。独自のアルゴリズムが設計されていて、これらの最適化プロセスを迅速に処理して、実行可能なギアプランを素早く見つけることができる。
オンラインサービングアーキテクチャ
オンラインサービングのために設計されたアーキテクチャは、プロデューサー-コンシューマーモデルに従う。このモデルは、3つの重要なコンポーネントで構成される:
- 推論サーバー:これらのサーバーはモデルをホストし、実行し、利用可能なGPUを管理し、ギアプランに従ってモデルがロードされるのを確保する。
- プロデューサー:ユーザーからのリクエストを受け取り、ギアプランに基づいて適切なキューに振り分けるコンポーネント。
- コンシューマー:コンシューマーは定期的にこれらのキューをチェックし、集められたサンプルが十分な数に達したときに推論をトリガーする。
このアーキテクチャは、各コンポーネントを独立してスケールさせることができるので、高いスケーラビリティを提供し、ボトルネックが全体のシステムパフォーマンスに影響を与えるのを防ぐ。
実験セットアップ
提案されたシステムの有効性を評価するために、一連の実験が行われ、2つの主要な作業負荷に焦点が当てられた:一つは速いモデル(BERT)のファミリーで、もう一つは遅いモデル(Llama)である。それぞれの作業負荷には:
- 一連のモデル。
- カスケードのパフォーマンスを測定するためのベンチマークタスク。
- クエリが発行されるタイミングをシミュレートする作業負荷トレース。
BERT作業負荷
BERT作業負荷はSentiment-140ベンチマークを使用して評価され、ツイートの感情分析を評価する。さまざまなBERTモデルを使ってカスケードを作成し、保持されたデータサンプルのセットでテストを行ってパフォーマンスを測定する。
テストでは、受信リクエストパターンは実際のツイートのタイムスタンプから導出される。システムに適切なストレスをかけるため、1秒あたりの最大クエリ数(QPS)が適切にスケーリングされ、負荷下でのシステムパフォーマンスを現実的に評価できる。
Llama作業負荷
同様に、Llama作業負荷はさまざまなモデルを使用して、HellaSwagという人気ベンチマークに基づいてパフォーマンスを評価する。Llamaのリクエストパターンは、実世界のアプリケーションからの呼び出しトレースに基づいて採用される。
各作業負荷は、システムを限界まで押し上げることを目的として設計されており、提案されたシステムと他の確立された手法との明確な比較を可能にする。
実験結果
テスト中、システムは以下のような主要な指標に基づいて評価される:
- コスト(使用したGPUの数で計測)。
- レイテンシ(予測を受け取るまでの遅延)。
- 出された予測の精度。
結果は、これらの指標間のトレードオフを示すようにプロットされ、さまざまな設定でのパフォーマンスパターンを特定するのに役立つ。
パフォーマンス比較
さまざまな実験を通じて、提案されたシステムは確立された基準を一貫して上回る。多くのケースで、最良の競合他社に比べて同じまたはそれ以上のパフォーマンスを達成しつつ、2〜3台少ないGPUを利用することができる。
特に、提案されたモデルは負荷の変動を効果的に処理しながら、高い精度を維持する。この適応性が、特に高い需要のある時期におけるパフォーマンスの鍵となる。
劣化の観察
システムは異なる指標のバランスを取らなければならないため、高いクエリ負荷に直面すると劣化が見られることが多い。一部のシステムはある指標を他よりも優先するかもしれないが、提案されたシステムはバランスを維持することができる。
BERT作業負荷は、システムがユーザーリクエストの急増に直面しても、パフォーマンス目標を満たすためにリアルタイムで調整できる様子を示している。モデルカスケードを慎重に使うことで、高負荷が全体の精度に与える影響を最小限に抑えている。
結論
機械学習モデルの複雑さと使用の増加は、品質を損なうことなくさまざまな作業負荷を処理できる効率的なサービングシステムの必要性を強調している。提案されたシステムはモデルカスケードを革新的に活用し、全体の予測プロセスを最適化し、現実の要求に適応している。
このシステムは既存の手法を上回ることが示されており、リソースコストを削減し、その信頼性の高い解決策としての可能性を強調している。機械学習アプリケーションの進化が進む中、こうした適応型システムの重要性はさらに高まっていくだろう。
推論サービングの重要なニーズに応えることで、提案されたシステムは、さまざまなアプリケーションや業界においてより効率的で正確かつコスト効果の高い予測を実現する道を切り拓いている。
タイトル: CascadeServe: Unlocking Model Cascades for Inference Serving
概要: Machine learning (ML) models are increasingly deployed to production, calling for efficient inference serving systems. Efficient inference serving is complicated by two challenges: (i) ML models incur high computational costs, and (ii) the request arrival rates of practical applications have frequent, high, and sudden variations which make it hard to correctly provision hardware. Model cascades are positioned to tackle both of these challenges, as they (i) save work while maintaining accuracy, and (ii) expose a high-resolution trade-off between work and accuracy, allowing for fine-grained adjustments to request arrival rates. Despite their potential, model cascades haven't been used inside an online serving system. This comes with its own set of challenges, including workload adaption, model replication onto hardware, inference scheduling, request batching, and more. In this work, we propose CascadeServe, which automates and optimizes end-to-end inference serving with cascades. CascadeServe operates in an offline and online phase. In the offline phase, the system pre-computes a gear plan that specifies how to serve inferences online. In the online phase, the gear plan allows the system to serve inferences while making near-optimal adaptations to the query load at negligible decision overheads. We find that CascadeServe saves 2-3x in cost across a wide spectrum of the latency-accuracy space when compared to state-of-the-art baselines on different workloads.
著者: Ferdi Kossmann, Ziniu Wu, Alex Turk, Nesime Tatbul, Lei Cao, Samuel Madden
最終更新: 2024-06-20 00:00:00
言語: English
ソースURL: https://arxiv.org/abs/2406.14424
ソースPDF: https://arxiv.org/pdf/2406.14424
ライセンス: https://creativecommons.org/licenses/by/4.0/
変更点: この要約はAIの助けを借りて作成されており、不正確な場合があります。正確な情報については、ここにリンクされている元のソース文書を参照してください。
オープンアクセスの相互運用性を利用させていただいた arxiv に感謝します。
参照リンク
- https://docs.aws.amazon.com/sagemaker/latest/dg/deploy-models-frameworks-triton.html
- https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/
- https://aws.amazon.com/blogs/machine-learning/deploy-large-models-on-amazon-sagemaker-using-djlserving-and-deepspeed-model-parallel-inference/
- https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/
- https://dl.acm.org/doi/pdf/10.1145/3341301.3359658
- https://arxiv.org/pdf/1611.06453.pdf
- https://people.eecs.berkeley.edu/~matei/papers/2020/mlsys_willump.pdf
- https://link.springer.com/article/10.1007/s13369-021-05670-z
- https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=9b161d3bdada78887e1a6332cb7b55214805da7%
- https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9335945