Meituan Visual GPU 推論サービスデプロイアーキテクチャの最適化の実践

オンライン推論サービスで使用される GPU リソースの増加と一般的な GPU 使用率の低下という課題に直面した Meituan Vision の R&D チームは、モデル構造とマイクロサービスを分割して最適化することを決定し、一般的で効率的な展開アーキテクチャを提案しました。パフォーマンスのボトルネックの問題。

「画像検出 + 分類」サービスを例にとると、最適化されたサービスプレッシャーテストパフォーマンスインデックスの GPU 使用率は 40% から 100% に増加し、QPS も 3 倍以上増加しました。この記事では、推論サービスデプロイアーキテクチャの最適化のエンジニアリングプラクティスに焦点を当て、あなたを助けたり刺激したりすることを望んでいます。

0.はじめに
1. 背景
2. ビジュアルモデルサービスの特徴と課題
- 2.1 モデル最適化ツールと展開フレームワーク
- 2.2 ビジュアルモデルの機能
- 2.3 視覚推論サービスの問題点と課題
3. GPU サービスの最適化の実践
- 3.1 画像分類モデルサービスの最適化
- 3.2 画像「検出＋分類」モデルサービスの最適化
4. 一般的で効率的な推論サービスのデプロイアーキテクチャ
5. まとめと展望

0.はじめに

Meituan Vision は地域の生活サービスを指向しており、テキスト認識、画質評価、ビデオ理解などの視覚 AI 技術を多くのシナリオに適用しています。以前は、オンライン推論サービスで使用される GPU リソースは増加し続けていましたが、サービス GPU の使用率は一般的に低く、多くのコンピューティングリソースを浪費し、視覚 AI アプリケーションのコストを増加させていました.これは Meituan と多くの企業が必要としている緊急の問題です.解決する。

Meituan の Visual Intelligence 部門は、実験的分析を通じて、ビジュアル推論サービスの GPU 使用率が低い重要な理由がモデル構造の問題であることを発見しました。モデルの前処理または後処理部分の CPU 動作速度は、これにより、推論バックボーンネットワークが GPU コンピューティングパフォーマンスを十分に活用できなくなります。これに基づいて、ビジュアル R&D チームは、モデル構造の分割とマイクロサービスを通じて、この一般的なパフォーマンスのボトルネックの問題を解決するための一般的で効率的な展開アーキテクチャを提案します。

現在、このソリューションは複数のコアサービスに適用されています。「画像検出 + 分類」サービスを例にとると、最適化されたサービスプレッシャーテストパフォーマンスインデックスの GPU 使用率は 40% から 100% に増加し、QPS は 3 倍以上増加しました。この記事では、関連する作業に従事している学生を支援または刺激することを期待して、推論サービスデプロイアーキテクチャの最適化のエンジニアリングプラクティスに焦点を当てます。

1. 背景

ますます多くの AI アプリケーションが本番アプリケーション段階に入るにつれて、推論サービスに必要な GPU リソースも急速に増加しています。調査データによると、国内の AI 関連業界における推論サービスのリソース使用量は 55% 以上を占めており、その割合は今後も増加し続けます。しかし、多くの企業が実際に直面している問題は、オンライン推論サービスの GPU 使用率が全体的に低く、改善の余地がたくさんあることです。

サービスの GPU 使用率が低い重要な理由の 1 つは、推論サービス自体にパフォーマンスのボトルネックがあり、極端なプレッシャー下でも GPU リソースを十分に活用できないことです。その意味で、「推論サービスのパフォーマンスを最適化し、GPU リソースの使用効率を改善し、リソースの使用コストを削減する」ことは非常に重要です。この記事では、アーキテクチャのデプロイの最適化によって精度、推論の遅延、およびその他の指標を確保することを前提として、推論サービスのパフォーマンスと GPU 使用率を改善する方法を主に紹介します。

2. ビジュアルモデルサービスの特徴と課題

近年、ディープラーニングの手法は、コンピュータビジョンのタスクにおいて目覚ましい進歩を遂げ、主流の手法になりました。ビジョンモデルの構造にはいくつかの特徴があり、既存の推論フレームワークでデプロイすると、パフォーマンスや GPU 使用率の面でサービスが要件を満たさない可能性があります。

2.1 モデル最適化ツールと展開フレームワーク

ディープラーニングモデルは通常、展開前に最適化ツールを使用して最適化されます。一般的な最適化ツールには、TensorRT、TF-TRT、TVM、OpenVINO などがあります。これらのツールは、オペレーターフュージョン、動的メモリ割り当て、精度キャリブレーションなどの方法により、モデルの実行速度を向上させます。モデルのデプロイは本番アプリケーションの最後のリンクであり、深層学習モデルの推論プロセスをサービスにカプセル化し、モデルのロード、モデルのバージョン管理、バッチ処理、サービスインターフェイスのカプセル化などの機能を内部で実装し、RPC/HTTP インターフェイスを外部に提供します。業界の主流の展開フレームワークは次のとおりです。

TensorFlow Serving : TensorFlow Serving (略して TF-Serving) は、機械学習モデルの展開のために Google によってリリースされた高パフォーマンスのオープンソースフレームワークです. TF-TRT 最適化ツールを内部で統合していますが、TensorFlow 以外のモデルには十分に適していませんフォーマット。
Torch Serve : TorchServe は、AWS と Facebook が共同で立ち上げた Pytorch モデル展開推論フレームワークで、簡単な展開、高性能、軽量という利点があります。
Triton : Triton は、Nvidia がリリースした高性能の推論サービスフレームワークで、TensorFlow、TensorRT、PyTorch、ONNX などの複数のフレームワークモデルをサポートし、マルチモデルの共同推論シナリオに適しています。

実際の展開では、どのフレームワークを選択しても、モデルの形式、最適化ツール、フレームワークの機能など、複数の要素を考慮する必要があります。

2.2 ビジュアルモデルの機能

ディープラーニングは、従来の方法とは異なり、特徴抽出や分類器などのモジュールを個別に設計する必要がなく、従来の方法のマルチモジュールタスクを単一のモデルに置き換えるエンドツーエンドの方法です。深層学習モデルは、分類、検出、セグメンテーション、認識などの視覚タスクで大きな利点を示し、従来の方法では達成できない精度を達成しています。一般的に使用される視覚分類モデル (ResNet、GoogleNet など) と検出モデル (YOLO、R-FCN など) には、次の特徴があります。

多数のネットワークレイヤー (GPU コンピューティングに適しています) : ResNet-50 を例にとると、ネットワークには 49 の畳み込みレイヤーと 1 つの完全に接続されたレイヤーが含まれ、最大 2500 万のパラメーターと 38 億の FLOP (浮動小数点オペランド) があります。モデルの推論には、GPU 並列アクセラレーションに適した多数の行列計算が含まれます。
入力画像サイズは固定です (前処理が必要です) : また、ResNet-50 を例にとると、ネットワークの入力は画像浮動小数点型の行列で、サイズは 224x224 に固定されています。したがって、バイナリコード化された画像をネットワークに送信する前に、デコード、スケーリング、クロッピングなどの前処理操作が必要です。

2.3 視覚推論サービスの問題点と課題

ビジュアルモデルの上記の特性により、モデルの展開と最適化には 2 つの問題があります。

不完全なモデル最適化: TensorRT、TF-TRT などのツールは、主にバックボーンネットワークの最適化を目的としていますが、前処理部分を無視しているため、モデル全体の最適化が十分でないか、最適化できません。たとえば、分類モデルの ResNet-50 のすべてのネットワーク層を最適化できますが、前処理の画像デコード (通常は CPU 操作) 操作 "tf.image.decode" は無視され、TF-TRT によってスキップされます。
複数モデルの展開の難しさ: ビジュアルサービスでは、複数のモデルを直列に組み合わせて機能を実現することがよくあります。たとえば、テキスト認識サービスでは、最初に検出モデルによってテキストの位置が特定され、次にテキスト位置の部分画像が切り取られ、最後に認識モデルに送信されてテキスト認識結果が取得されます。サービス内の複数のモデルは、異なるトレーニングフレームワークを使用する場合があります. TF-Serving または Troch Serve 推論フレームワークは、展開要件を満たすことができない単一のモデル形式のみをサポートします. Triton はさまざまなモデル形式をサポートしており、モデル間の組み合わせロジックは、カスタムモジュール (バックエンド) と統合されたスケジューリング (Ensemble) によって構築できますが、実装は比較的複雑であり、全体的なパフォーマンスに問題がある場合があります。

これら 2 つの一般的なモデル展開の問題は、視覚的推論サービスのパフォーマンスのボトルネックと GPU 使用率の低下につながります. 高性能の展開フレームワークである Triton でさえ、解決するのは困難です.

一般的なデプロイフレームワークは、サービスホスティングにおける「通信方法、バッチ処理、マルチインスタンス」などのパフォーマンスの問題に焦点を当てていますが、モデル自体の特定の部分 (画像の前処理や後処理など) にボトルネックがある場合は、最適化ツールはそれを最適化できません。「バレル効果」が発生し、推論プロセス全体のパフォーマンスが低下します。したがって、推論サービスにおけるモデルのパフォーマンスのボトルネックをどのように最適化するかは、依然として重要かつ挑戦的な作業です。

3. GPU サービスの最適化の実践

分類と検出は、最も基本的なビジョンモデルの 2 つであり、画像のレビュー、画像ラベルの分類、顔検出などのシナリオでよく使用されます。以下では、単一の分類モデルの使用と、「分類 + 検出」の複数モデルの組み合わせの使用という 2 つの典型的なサービスをケースとして使用して、具体的なパフォーマンス最適化プロセスを紹介します。

3.1 画像分類モデルサービスの最適化

Meituan には毎日数千万枚の写真があり、それらをレビューしてフィルタリングして危険なコンテンツをフィルタリングする必要があります.手動レビューのコストは高すぎます.自動機械レビューを実現するには画像分類技術が必要です. 一般的に使用される分類モデルの構造を図 1 に示します。前処理部分は主に「デコード、スケーリング、クロッピング」などの操作を含み、バックボーンネットワークは ResNet-50 です。前処理部は、画像バイナリストリームを受信し、バックボーンネットワークが必要とするマトリックスデータ Nx3x224x224 (それぞれ、ピクチャ数、チャネル数、画像の高さ、および画像の幅を表す) とバックボーンネットワークを生成します。出力画像分類結果を予測します。

図1 画像分類モデル構造の模式図

TF-TRT 最適化後のモデルの実際の構造は下の図 2 に示されています. バックボーンネットワーク ResNet はエンジンとして最適化されますが、前処理部分の演算子は最適化をサポートしていないため、前処理部分全体が元の状態のままです. .

図 2 画像分類モデル TF-TRT 最適化構造図

3.1.1 パフォーマンスのボトルネック

モデルは TF-TRT によって最適化された後、TF-Serving フレームワークを使用してデプロイされます. サービスプレッシャーテストの GPU 使用率はわずか 42% であり、QPS と Nvidia の公式データの間には大きなギャップがあります. TF-TRT や Tensorflow フレームワークなどの可能性のある影響要因を除外し、最終的に前処理部分に焦点を当てます。Nvidia によるパフォーマンステスト用のモデルは前処理されておらず、Nx3x224x224 行列データが直接入力されています。ただし、ここでのオンラインサービスには前処理部分が含まれており、ストレステスト指標の CPU 使用率は比較的高くなっています。モデル内の各オペレーターの操作機器を確認すると、モデルの前処理の大部分が CPU コンピューティングであり、バックボーンネットワークが GPU コンピューティングであることがわかります (詳細については、図 1 を参照)。

下の図 3 に示すように、モデルが NVIDIA Nsight システム (nsys) ツールを介して実行されているときの CPU/GPU 実行ステータスを確認すると、GPU 操作の間に明らかな間隔があることがわかります.CPU データを待つ必要があります.バックボーンネットワークの推論を実行する前に、準備して GPU にコピーする必要があります。計算すると、CPU の処理速度が遅いと GPU が飢餓状態になります。サービスストレステストの CPU/GPU 使用率データと組み合わせると、高い CPU 消費量と前処理部分の処理速度の遅さが、推論サービスのパフォーマンスのボトルネックであることがわかります。

図 3 分類モデル nsys パフォーマンス診断図

3.1.2 最適化方法

以下の図 4 に示すように、前処理の高い CPU 消費が推論サービスのパフォーマンスに影響を与えるという問題を解決するために、いくつかの最適化方法が提案されています。

図4 最適化手法の比較

CPU を増やす: マシンの CPU の数を増やす最も簡単な方法ですが、サーバーのハードウェア構成によって制限され、通常、1 つの GPU は 8 つの CPU でしか構成されません。したがって、CPU を増やす方法は、パフォーマンステストデータの比較にのみ使用でき、実際のアプリケーションに展開することはできません。
前処理: 大きなサイズの画像のデコードおよびスケーリング操作は多くの CPU を消費しますが、小さなサイズの画像の処理速度ははるかに高速です。したがって、事前に入力画像を前処理し、前処理された小さな画像をサービスに送信することを検討してください。Tensorflow のスケーリングとクロッピング操作には重ね合わせ不変性があることが検証されています。つまり、複数の操作と単一の操作は最終結果に影響しません。前処理された小さな画像は、生の分類サービスに送信される前にエンコードされます。画像のエンコードにはロスレスエンコード (PNG など) を選択する必要があることに注意してください。そうしないと、デコードされたデータに一貫性がなくなり、予測エラーが発生します。前処理方式の利点は、元のモデルサービスを変更する必要がなく、操作性が高く、予測結果に誤差がないことです。欠点は、前処理を繰り返す必要があるため、全体的なプロセスの遅延が増加し、CPU リソースが浪費されることです。
別の前処理: 別のアイデアは、モデルの前処理部分をバックボーンネットワークから分離し、前処理部分を CPU マシンに個別にデプロイし、バックボーンネットワークを GPU マシンにデプロイすることです。このアプローチにより、CPU 前処理サービスを水平方向に無限に拡張して、GPU 処理のデータ供給を満たし、GPU のパフォーマンスを最大限に活用できます。さらに重要なことは、CPU と GPU の操作を切り離すことで、CPU と GPU のデータ交換の待ち時間が短縮され、理論的には CPU の数を増やすよりも効率的であるということです。通信効率とサービス間の時間だけを考慮する必要があります.トリミングされた画像のサイズは224x224x3であり、符号なし整数のデータサイズは143KBです.伝送時間と帯域幅は10,000 QPS以下で問題ありません.

3.1.3 最適化結果

以下の図 5 に示すように、NVIDIA Nsight システムを使用して、上記の方法で最適化されたモデルの動作を比較します。CPU と事前前処理を増やす方法は、CPU の前処理時間を短縮し、GPU データの待機時間を短縮し、GPU の使用率を向上させることができます。しかし、比較すると、前処理を分離する方法はより徹底的に最適化されており、CPU から GPU へのデータコピー時間は最短であり、GPU は十分に活用されています。

図5 最適化手法nsys性能診断の比較表

さまざまな方法で最適化されたオンラインサービスプレッシャーテストのパフォーマンス結果を下の図 6 に示します (前前処理および分離前処理の CPU 前処理サービスは、追加の 16 個の CPU を使用します)。マシンに構成されている CPU モデルは Intel(R) です。 Xeon(R) Gold 5218 [email protected]、GPU モデルは Tesla T4 です。圧力テストの結果から、次のことがわかります。

図6 最適化結果の性能比較

1. サービス CPU が 32 コアに増加し、QPS および GPU 使用率 (nvidia-smiコマンドによって取得される GPU-Util インジケーター) が 1 倍以上増加し、GPU 使用率が 88% に増加しました。

2.前処理方法が最適化された後、サービス QPS は 2 倍以上になり、CPU を増やす方法よりもわずかに優れていますが、GPU 使用率の観点からはまだ最適化の余地がたくさんあります。

3. 分離前処理方法が最適化された後、QPS は 2.7 倍に増加し、GPU 使用率は 98% に達し、フルロード状態に近づきます。

CPU を増やしても、サービスパフォーマンスのボトルネックの問題を完全に解決することはできません.GPU 使用率は 88% に達しますが、CPU-GPU データ転送時間は大きな割合を占め、QPS の改善は限定的です. 前処理方法では、前処理のパフォーマンスのボトルネックの問題が完全に解決されるわけではなく、最適化も完全ではありません。比較すると、個別の前処理方法は、GPU のコンピューティングパフォーマンスを最大限に活用し、QPS および GPU 使用率インジケーターでより優れた最適化結果を達成します。

3.2 画像「検出＋分類」モデルサービスの最適化

一部の複雑なタスクシナリオ (顔の検出と認識、画像テキストの認識など) では、通常、検出、セグメンテーション、分類などの複数のモデルを組み合わせて機能を実現します。このセクションで紹介するモデルは、一連の「検出 + 分類」で構成されており、モデル構造は下の図 7 に示すように、主に次の部分で構成されています。

図 7 元のモデル構造の概略図

前処理: 主に画像のデコード、スケーリング、塗りつぶしなどの操作を含み、Nx3x512x512 の画像マトリックスを出力します. ほとんどの演算子は CPU デバイスで実行されます.
検出モデル: 検出ネットワーク構造は YOLOv5、オペレーター実行デバイスは GPU です。
検出後処理: NMS (非最大値抑制) アルゴリズムを使用して重複または誤検出されたターゲットフレームを削除し、有効な検出フレームを取得してから、ターゲット領域のサブ画像をトリミングおよびスケーリングし、Nx3x224x224 画像マトリックスを出力し、ほとんどの画像を実行します。 CPU デバイスでの検出後のオペレーター。
分類モデル: 分類ネットワーク構造は ResNet-50 で、オペレーター実行デバイスは GPU です。

検出と分類の 2 つのサブモデルは個別にトレーニングされ、推論中に単一のモデルにマージされます. 展開フレームワークは TF-Serving を使用し、最適化ツールは TF-TRT を使用します.

3.2.1 パフォーマンスのボトルネック

モデルの前処理と検出後処理のほとんどは CPU 演算であり、検出モデルと分類モデルのバックボーンネットワークは GPU 演算であり、1 つの推論プロセスで複数の CPU-GPU データ交換が必要です。同様に、CPU の動作速度が遅いと GPU の使用率が低くなり、推論サービスでパフォーマンスのボトルネックが発生します。

実際のオンラインサービスプレッシャーテストでは、GPU 使用率が 68% であり、QPS にも最適化の余地が大きいことが示されています。サービス構成は1GPU+8CPU（マシンのCPUモデルはIntel(R) Xeon(R) Gold 5218 [email protected]、GPUモデルはTesla T4）。

3.2.2 最適化方法

モデル分割の考え方は今でも採用されており、マイクロサービスは CPU と GPU のコンピューティング部分に個別にデプロイされています。以下の図 8 に示すように、元のモデルを 4 つの部分に分割し、前処理と検出後処理を CPU マイクロサービス (トラフィック量に応じて動的に拡張可能) としてデプロイし、検出モデルと分類モデルをデプロイします。 GPU マイクロサービス (同じ GPU カード) として。呼び出し方法をシンプルに保つために、上位層はスケジューリングサービスを使用してさまざまなマイクロサービスを直列に接続し、統一された呼び出しインターフェイスを提供し、呼び出しの違いを上流から隠します。TensorRT で分割検出モデルと分類モデルを最適化した後、Triton でデプロイします。

図8 モデル最適化展開体制の模式図

3.2.3 最適化結果

以下の図 9 に示すように、元のサービスとマイクロサービスの分割に加えて、CPU と Triton Ensemble を追加した場合のパフォーマンステスト結果も比較されます。Triton Ensmeble メソッドは、マルチモデルパイプラインスケジューリングを実現するために、すべてのサブモデル (前処理と後処理を含む) を 1 台のマシンに展開します。比較から次のことがわかります。

図9 最適化結果の性能比較

元のサービスの CPU は 32 コアに増加し、GPU 使用率は 90% に増加しますが、QPS の増加は 36% にすぎません。
元の TF-Serving サービスと比較すると、Triton Ensemble メソッドにはパフォーマンスのギャップがほとんどありません。
モデル分割マイクロサービス方式の最適化後、QPS は 3.6 倍に増加し、GPU 使用率は 100% の全負荷に達します。

CPU を増やす方法は、サービスの GPU 使用率を大幅に改善しますが、QPS の改善は明らかではありません.理由は、CPU の前処理時間と後処理時間が短縮されるためですが、CPU-GPU データ転送時間は依然として考慮されています.推論プロセス全体で大きな割合を占め、GPU の計算時間は比較的長くなります。

分割モデルは、Triton Ensmeble を使用して展開され、マルチモデルスケジューリングパイプラインを実装します。効率はモデル分割前よりも高くありません。マルチモデルパイプラインが同一マシン上にあるため、CPU と GPU 間の相互影響の問題は解決されておらず、GPU の処理効率は CPU によって制限されています。モデル分割マイクロサービス展開方法は、サービスレベルで呼び出しパイプラインを実現し、CPU 前処理および後処理マイクロサービスは、トラフィックに応じてリソースを動的に増やして、GPU モデルマイクロサービスのスループット要件を満たし、GPU/CPU 処理の分離を実現し、回避することができます。 CPU処理がボトルネックになります。

全体として、マイクロサービスを分割する方法は、GPU のコンピューティングパフォーマンスを最大限に活用し、QPS および GPU 使用率インジケーターに関してより良い結果を達成します。

4. 一般的で効率的な推論サービスのデプロイアーキテクチャ

上記の 2 つの代表的な推論サービスの最適化ケースに加えて、他の多くのビジュアルサービスもこの最適化方法を採用しています。この最適化方法にはコアアイデアがあります。CPUコンピューティングがボトルネックとなる推論サービスでは、モデルの CPU および GPU コンピューティング部分を分割し、CPU/GPU マイクロサービスとして別々にデプロイします。

この考えに基づいて、一般的で効率的な推論サービス展開アーキテクチャを提案します。以下の図 10 に示すように、最下層は共通の展開フレームワーク (TF-Serving/Triton など) を使用し、前処理や後処理などのモデル内の CPU コンピューティング部分は分割され、CPU マイクロサービスに個別に展開されます。バックボーンネットワークモデルは GPU サービスとして展開され、上位レベルのスケジューリングサービスはモデルマイクロサービスを接続して、全体的な機能ロジックを実現します。

図 10 一般的なサービス展開アーキテクチャの概略図

ここで重要な質問を説明する必要があります。なぜこの展開アーキテクチャは効率的ですか?

まず、マクロレベルでは、モデルが分割されてマイクロサービスに展開され、サブモデルのパイプライン処理がスケジューリングサービスによって実現されます。分割サブモデル CPU マイクロサービスは、トラフィックと処理能力に応じて動的に拡張でき、モデルの前処理または後処理の CPU コンピューティング能力がパフォーマンスのボトルネックとなるのを回避し、GPU モデルマイクロサービスのスループット要件を満たします。

第 2 に、ミクロレベルでは、モデルに複数の CPU/GPU コンピューティングパーツが含まれている場合、GPU コンピューティング間にギャップが生じます。以下の図 11 に示すように、1 つの推論プロセスでは、2 つの GPU 操作の間に CPU 後処理部分が完了するのを待つ必要があり、CPU 前処理は GPU 操作にも影響します。モデルが分割された後、前処理部分と後処理部分は個別に CPU サービスとして展開されます. GPU サービスの推論プロセスには 2 つのサブモデル操作部分のみが含まれ、サブモデル間の操作はそれぞれ独立しています. CPU-GPUのデータ転送部分はGPUに接続可能計算処理は並列で、理論上はGPUで100%の演算効率を実現できます。

図 11 推論プロセス比較の模式図

また、遅延に関しては、マイクロサービスを分割してデプロイする方法では、RPC 通信とデータコピーの時間オーバーヘッドが増加しますが、実際には、この部分の時間はわずかな割合であり、エンドツーエンドに大きな影響を与えることはありません。終了遅延。たとえば、上記のセクション 3.1 の分類モデルの場合、最適化前の平均サービス時間は 42 ミリ秒であり、最適化後のマイクロサービス形式 (RPC 通信プロトコルは Thrift) での平均サービス時間は 45 ミリ秒です。通常、このレベルのレイテンシの増加は、ほとんどのビジョンサービングのユースケースでは影響を受けません。

5. まとめと展望

この記事では、2 つの典型的なビジュアル推論サービスを例として使用して、モデルパフォーマンスのボトルネックと GPU 使用率の低下の問題に対する最適化プラクティスを紹介します. 最適化後、サービスの推論パフォーマンスは約 3 倍向上し、GPU 使用率はほぼ 1 倍になりました. 100%。最適化の実践に従って, この論文は一般的で効率的な推論サービス展開アーキテクチャを提案します. このアーキテクチャはビジュアルモデルサービスに限定されず, 他の分野のGPUサービスも参照に使用できます.

もちろん、この最適化手法にもいくつかの欠点があり、たとえば、最適化プロセスでモデルを分割する方法は、手作業の経験または実験的テストに依存しており、最適化プロセスの自動化と標準化は実現されていません。将来的には、モデルのボトルネックを自動的に診断し、プロセス全体の自動分割と最適化をサポートするモデルパフォーマンス分析ツールを構築する予定です。