HUOXIU

Bilibiliの大規模AIモデル推論の実践


出典: Bilibili Technology


I. 背景


  • AI アルゴリズムの複雑さは年々増大しており、AI モデルの推論と展開をサポートするための効率的な方法が必要になっています。

  • アプリケーションの規模が拡大するにつれて、コンピューティング リソースの消費も急速に増加し、オンライン リソースに大きな負担がかかります。

  • Bilibili の AI には、コンピューター ビジョン (CV)、自然言語処理 (NLP)、音声などの複数のシナリオが含まれており、コンテンツのセキュリティ レビュー、コンテンツの理解、作成など、数百のアプリケーション シナリオに対応します。


II. 課題と目標


チャレンジ


  • オンライン リソースはトラフィックとともに直線的に増加するため、コスト削減と効率性向上の観点から、オンライン リソースの増加を制御したいと考えています。

  • 業界での大規模言語モデルの推進と実装により、BERT、GPT、T5-Large モデルが NLP シナリオに導入され、モデルの複雑さが大幅に増加しました。

  • フレームレベルの動画処理。例えば、OCR(光学文字認識)シナリオでは、24時間以内に10億枚を超える720p画像が処理されました。これは、モデル推論とモデルサービスに大きな負担をかけています。



  • トラフィックの増加とアルゴリズムの複雑化により、オンライン サービスの応答時間と QPS に大きな課題が生じています。

  • 多数のロングテールシナリオにアクセスするには、統一されたアプローチが必要です。


ターゲット


  • 推論スループットを向上させ、リソースの増加率を削減します。

  • 応答時間を改善し、サービス品質を強化します。

  • 新規ビジネスに進出し、より多くのシナリオに実装します。


III. InferX推論フレームワークの紹介


上記の問題に対処するため、私たちは独自の推論フレームワークを開発しました。社内コードネームはInferXです。アーキテクチャ図を以下に示します。

一般的な推論フレームワークは、インタープリタ、グラフオプティマイザ、バックエンドなどのコンポーネントに分解できます。上記のコンポーネントに加えて、InferXはスパース性や量子化といったいくつかの計算前最適化をサポートしています。



InferX の最近の反復には、主に次の側面が含まれています。

  • ONNXリンクをサポートし、TensorflowおよびPaddleモデルのサポートを可能にします。モデルのデプロイメント効率が向上します。

  • InferX ランタイムの改善、リソース取得方法の最適化、CPU 使用量の削減。

  • モデルのフロントリンク最適化機能: int8とスパース性をサポート

  • 画像演算子の機能を拡張します。


IV. InferX推論フレームワークの事前計算リンク


InferX の事前計算処理とは、モデルが稼働する前にモデルに対して実行されるいくつかのオフライン プロセスを指し、現在は主に量子化とスパース化が含まれます。


モデルの量子化:


  • FP16 と比較して、INT8 TensorCore は 2 倍のパフォーマンスを提供します。

  • InferX は量子化 SDK を実装しており、モデルの量子化が比較的便利になります。

  • PTQ 定量化は、OCR および著作権のシナリオではすでに実装されています。

  • 上の図はInferXの量子化プロセスを示しています。InferXはTensorRT Lowering Graph Optimizerを実装している点にご留意ください。このグラフオプティマイザーを省略すると、量子化モデルの高速化は実現されません。

  • 下の図は、著作権モデル推論シナリオにおける量子化の利点を示しています。量子化により、ほぼロスレスのモデル精度を実現しながら、2倍の高速化を実現します。




モデルの構造化されたスパース性:


  • NVIDIA は、Ampere アーキテクチャから、Sparsity TensorCore のパフォーマンスを活用する 2:4 スパース スキームをサポートしています。

  • トレーニング後のプルーニングは、アルゴリズムと連携して、スパース モデルのチェーンを完成させます。

  • スパース構造をサポート

  • 稠密TensorCoreと比較すると、スパースTensorCoreは2倍の高速化を実現します。ただし、スパースTensorCoreは畳み込み演算と線形演算にしか適用できないため、全体的な高速化は2倍未満です。例えば、下の図では、ロングテールカーネルはsparsity-tensorcoreを使用して最適化できません。



  • FP16 スパース テンソル コアには一部のモデルで精度の問題がありますが、エンジニアリングでは混合精度計算を使用して解決できます。


V. InferXを使用して主要シナリオを最適化する

— OCRを例に挙げると


プロジェクトの背景:


  • OCR は監査機能の重要なコンポーネントです。

  • OCR ではフレームごとの処理が必要となり、大量の計算リソースが消費されます。

この章では、主要なシナリオを最適化する方法について説明しており、関連するテクノロジは InferX に限定されないことに注意してください。


モデルの適応:


OCRは直接エクスポートできないサードパーティ製の演算子を使用しているため、InferXはモデル交換フォーマットとしてONNXをサポートし、ONNXモデルをグラフ中間表現に変換するONNXパーサーを実装することで、この制限に対処しています。さらに、OCRはサードパーティ製の演算子である変形可能畳み込みを使用するため、その実装をバックエンドに追加する必要があります。この変形可能畳み込み技術は、その後、複数の検出シナリオで再利用されています。



CUDAに基づく変形可能な畳み込みの実装


  • CUDA 演算子を最適化することでパフォーマンスを向上します。

  • NHWC バージョンでは変形可能な畳み込みを実装し、im2col 操作のメモリ アクセス効率を向上させます。

  • メモリ アライメントを実現するために、行列乗算の m/n/k 値は 8 の倍数にパディングされ、計算にテンソル コアが使用されるようになります (これは CUDA 11 より前の制約であったことに注意してください。CUDA 11 以降では、TensorCore の使用は上記の制限を受けなくなります)。

  • 下の図は、im2col を実行する際の NCHW レイアウトと NHWC レイアウトの違いを示しています。従来の NCHW メモリレイアウトと比較して、NHWC はメモリとキャッシュの効率性が高く、メモリ結合も実行できるメモリレイアウトです。



構造化スパース性に基づくモデルの加速

  • InferX はスパース モデルの構築をサポートし、レイヤー精度の明示的な定義を可能にすることで、精度の問題を解決します。

  • 認識モデルが約 25% 高速化されます。


CUDAベースのJPEGデコーダーの最適化


  • libjpeg のデコード関数は CPU を大量に消費するタスクです。CPU 使用率が高すぎるとサービスの安定性に影響を与える可能性があり、libjpeg は既に非常に成熟しているため、最適化が困難です。

  • これは、nvjpeg をカプセル化し、ハードウェア デコード、CUDA デコード、CPU デコードをサポートする inferx_cv デコード ライブラリを実装します。

  • JPEG デコードに CUDA を使用すると、CUDA は GPU 使用率を非常に低く抑えて JPEG をデコードし、CPU の 4 分の 1 の時間しかかかりません。


ビデオ/ライブストリーム OCR リソースの再利用と同期変換


  • 以前のアーキテクチャでは、ビデオ/ライブ OCR は別々のモデル サービスでした。

  • 古いアーキテクチャでは非同期 gRPC を使用していましたが、ビデオ/ライブ OCR のプロトコルは異なります。

  • モデルサービスを同時に変更することでプロトコルが統一され、ビデオとライブストリーミングでモデルサービスが共有され、応答時間とサービスの安定性が向上しました。

  • モデル サービスは優先順位をサポートするようになり、ライブ ストリーミング リクエストに高い優先順位が与えられます。

  • ビデオ サービスとライブ ストリーミング サービスのトラフィック傾向の違いを活用することで、オンライン マシンの GPU 使用率が大幅に向上しました。

上記の最適化により、OCRサービスはGPU使用率80%で安定的に動作し、応答時間も短縮されます。最適化前と比較して、総リソースは63%削減されます。


VI. トリトンモデルサービスの紹介


推論フレームワークと比較すると、モデル サービスは、全体的なリソース使用率を高めるためにスループットと並列処理の向上に重点を置いています。



チャレンジ:

  • さまざまなビジネス オペレーションで使用されるさまざまな種類のモデルに対して、モデルを迅速にオンライン化できるように、統合されたエンジニアリング ワークフローが提供されます。

  • 同部門が独自に開発した推論加速フレームワーク「InferX」は推論時間を短縮できますが、GPU リソースの利用率を高めるにはスループットの向上も必要です。

  • 多くのビジネス オペレーションでは複数のモデルが使用され、モデル間には論理的かつ依存関係があるため、モデルの直列/並列接続を調整する機能が必要になります。

上記の問題に対処するために、一般的に使用されているオープンソース フレームワーク (Triton、TF-Serving など) を調査し、最終的に次の機能を提供する Nvidia Triton Inference Server に基づくモデル推論サービスを選択しました。

  • PyTorch、Tensorflow、ONNX、Python、DALI、TensorRTなど、複数のディープラーニングフレームワークをサポートし、これらのフレームワークで生成されたモデルをデプロイできます。また、カスタムモデルフレームワークもサポートしています。

  • モデルオーケストレーション(BLS)をサポートします。マルチモデルのカスケード/並列シナリオでは、Pythonを使用してモデルオーケストレーションコードを記述することで、(1)前処理、(2)推論用のテンソルを各モデルに分配して結果を収集、(3)後処理というプロセス全体を完了できます。

  • 動的バッチ処理がサポートされています。つまり、モデルサービスへのリクエスト送信時に事前にバッチを作成する必要はありません。Tritonは必要に応じて自動的にバッチ処理を実行し、推奨バッチサイズ、キューサイズ、デフォルトのタイムアウトなどのバッチパラメータを設定できます。

  • HTTP/gRPC クライアントを提供し、推論サービスの上流配信側からのアクセスを容易にします。

  • メトリックをサポートし、QPS、エラー数、レイテンシ、GPU 使用率などのリアルタイム パラメーターを自動的に収集します。


VII. トリトンモデルサービス

+InferX推論フレームワーク


InferX 推論フレームワークを Triton モデル サービスに統合すると、低レイテンシと高スループットという AI モデル推論の究極の状態が実現します。



推論プロセス:


  • 同時HTTP/gRPCリクエストがTritonに到着すると、モデルキューに入り、到着時間に応じて動的にバッチ処理されます。これは手動でリクエストをバッチ処理するよりもはるかに効率的であり、リクエストのバランスをより保つことができます。

  • バッチリクエストは、モデルオーケストレーションスクリプト(BLS)を介して各サブモデルに非同期的に配布されます。InferX推論フレームワークを使用するサブモデルは、推論を高速化し、推論リクエストを最短時間で完了します。

  • 複数のモデルが並列で関与するシナリオでは、複数のモデルが同じ入力テンソルを使用して完全に並列な操作を実行でき、結果は内部で非同期的に収集されますが、全体的なインターフェースは外部的に同期されたままになります。

  • 複数のモデルが連続して含まれるシナリオでは、パイプラインの再利用により、ネットワーク転送と複数のリクエストのキュー待機時間がカバーされ、GPU がアイドル状態になる時間が最小限に抑えられます。

  • 推論結果は同期的に返され、監視指標は均一に報告されます。


パフォーマンスの向上:


  • AIはすでにTritonモデルサービスを広範囲に導入しています。手書きのPythonサービスフレームワークと比較して、単一インスタンスのスループットは3~8倍向上し、GPUカードの枚数を50%削減し、ストレステストにおいて90%を超えるGPU使用率を達成しています。

  • InferX 推論フレームワークの 4 ~ 7 倍の推論加速と組み合わせることで、グラフィック カードのパフォーマンスは基本的に限界まで圧縮され、GPU 調達を増やすことなくビジネス トラフィックの増加をサポートします。


VIII. 要約


自社開発の推論フレームワーク「InferX」とモデルサービス「Triton」を導入することで、コンピューティングリソースの利用効率を大幅に向上し、リソースコストを削減、サービスの応答時間と安定性を確保、AIサービスの開発・導入コストを削減し、さまざまな業務の実装をより迅速に支援できるようになりました。