AIの大規模導入における大きなギャップを埋めます！アリババ、テンセント、百度などが共同でインターネットサービスAIベンチマークを開始

[[276827]]

今日、インターネット サービスは根本的な変化を遂げており、徐々にインテリジェント コンピューティングの時代へと移行しています。現代のインターネット サービス プロバイダーは、サービスを強化するために人工知能をよく利用しています。このような状況の中で、研究者は多くの革新的な AI アルゴリズム、システム、アーキテクチャを提案しており、ベンチマークと評価ベンチマークの重要性が高まっています。しかし、現代のインターネット サービスでは、さまざまなモジュールで構成されるマイクロサービス ベースのアーキテクチャが採用されています。これらのモジュールの多様性と実行パスの複雑さ、データセンター インフラストラクチャの大規模で複雑な階層、データセットとワークロードの機密性は、設計ベンチマークに大きな課題をもたらします。

この論文では、Baidu、Alibaba、Tencent などの大手インターネット サービス プロバイダーが、中国のインターネット企業 17 社と共同で、業界標準のインターネット サービス AI ベンチマークである AIBench を立ち上げました。 AIBench は、高度にスケーラブルで、構成可能で、柔軟なベンチマーク フレームワークを提供します。著者らは、検索エンジン、ソーシャル ネットワーク、電子商取引という 3 つの最も重要なインターネット サービス分野において、16 の顕著な AI 問題領域を特定しました。著者らは、AIBench フレームワークに基づいて、実際のデータセットとワークロードを使用して、初のエンドツーエンドのインターネット サービス AI ベンチマークを設計および実装しました。著者らは、CPU および GPU クラスター上のエンドツーエンドのアプリケーション ベンチマークの予備評価を実行します。 AI 関連コンポーネントは、インターネット サービスのクリティカル パスとワークロード特性を大幅に変更し、エンドツーエンドの AI アプリケーション ベンチマークの正確性と必要性​​を証明します。この論文は、これまでで最も包括的な AI ベンチマーク研究です。この AI ベンチマーク作業については、AI Frontier の第 92 論文の紹介で詳しく説明します。

1. はじめに

人工知能技術の進歩は、画像、ビデオ、音声、オーディオなどの処理技術に画期的な進歩をもたらし、大規模な人工知能アルゴリズム、システム、アーキテクチャの導入を促進しました。そのため、現代のインターネットサービスプロバイダーは、一般的に人工知能を採用してサービスを強化しています。たとえば、Alibaba はより効果的なパーソナライゼーションを実現するために新しい DUPN ネットワークを提案しました。 Google はサービスのパフォーマンスを向上させるために TensorFlow システムと TPU をリリースしました。 Amazon はスマートな商品推奨のために人工知能を活用しています。

その結果、これらのアルゴリズム、システム、アーキテクチャを測定し評価することへのプレッシャーが高まっています。まず、現実世界のデータセットとワークロードはインターネット サービス プロバイダーによって極秘事項とみなされており、さらなる研究に使用できるのは、産業規模のインターネット サービスに関する公開されているパフォーマンス モデルや研究結果のごく一部だけです。公開インターネット サービスのベンチマークがなければ、インターネット サービスの現状を押し進めることができるのは内部の研究者だけとなり、これは持続不可能な状態となり、オープン インターネット サービスの発展に大きな障害を生み出します。

第二に、人工知能はインターネットサービスのほぼすべての側面に浸透しています。したがって、現実世界の AI シナリオの主要なパスと顕著な特徴をカバーするには、エンドツーエンドのアプリケーション ベンチマークを提供する必要があります。代表的なデータセットを見つけ、主要なAI 問題領域 (コンポーネント ベンチマーク)を要約し、さらに最も集中的なコンピューティング ユニット (マイクロ ベンチマーク) を理解する必要があります。これに基づいて、簡潔で包括的な AI ベンチマーク フレームワークを構築できます。

最後に、アーキテクチャの観点から見ると、初期段階で完全な AI アプリケーションを新しいアーキテクチャに移植することは困難、あるいは不可能になる場合があります。後の段階では、マイクロベンチマークやコンポーネントベンチマークのみを使用するだけでは、さまざまなモジュールの詳細な分析を実行したり、実際のアプリケーションシナリオのボトルネックを特定したりするには不十分です。現在の最先端の AI ベンチマークでは、少数のマイクロベンチマークまたはコンポーネントベンチマークしか提供されておらず、業界規模のインターネット サービスのすべてのケースをカバーできるものはありません。したがって、すべてのマイクロベンチマークまたはコンポーネントベンチマーク、およびエンドツーエンドのアプリケーションベンチマークで構成されるインターネットサービス AI ベンチマークを構築することは、この大きなギャップを埋めるために非常に重要です。

論文寄稿:

• 高度にスケーラブルで、構成可能で、柔軟な人工知能ベンチマーク フレームワークが提案され、実装されています。
• 17 の業界パートナーと協力して、16 の主要な AI 問題領域を特定し、それらの領域に応じて 16 のコンポーネント ベンチマークを実装しました。
• 私たちは、基盤となる電子商取引検索モデルを含む、業界初のエンドツーエンドのインターネット サービス AI ベンチマークを設計し、実装しました。
• エンドツーエンドのインターネット サービス AI ベンチマークが CPU および GPU クラスターに実装され、パフォーマンス、動作効率、実行時間の詳細な分析が行われ、さらなる最適化のためのガイダンスが提供されました。

表1: AIベンチマークの比較

2. AIBenchフレームワーク

2.1 フレームワーク構造

AIBench フレームワークは、図 1 に示すように、汎用的で柔軟性があり、構成可能な AI ベンチマーク フレームワークを提供します。データ入力、AI 問題領域、オンライン推論、オフライン トレーニング、展開ツール モジュールなど、エンドツーエンドのアプリケーションを形成するために構成および拡張できる疎結合モジュールを提供します。

図1: AIBenchフレームワーク

データ入力モジュールは、他のモジュールにデータを入力する役割を担います。このモジュールは、権威ある公開 Web サイトから代表的な現実世界のデータセットを収集するだけでなく、匿名化された上で業界パートナーからデータセットも収集します。このデータ モデルに基づいて、ユーザー情報や製品情報などの大規模なデータ生成をサポートする一連のデータ ジェネレーターがさらに提供されます。このフレームワークは、さまざまなオープンソース データ ストレージ システムを統合し、大規模データの生成と展開をサポートします。

フレームワークの多様性と代表性を実現するために、著者らはまず、最も重要なインターネット サービス領域で重要な役割を果たす顕著な AI 問題領域を特定します。次に、これらの AI 問題領域をコンポーネント ベンチマークとして使用して、人工知能アルゴリズムの具体的な実装を示します。さらに、これらのコンポーネント ベンチマークの最も集中的な計算ユニットがプロファイルされ、マイクロベンチマークのセットとして実装されます。

このフレームワークは、エンドツーエンドのアプリケーション ベンチマークを構築するためのオフライン トレーニングおよびオンライン推論モジュールも提供します。まず、オフライントレーニングモジュールは、必要なベンチマークID、入力データ、実行パラメータ（バッチサイズなど）を指定して、AI問題ドメインモジュールから1つ以上のコンポーネントベンチマークを選択します。次に、オフライン トレーニング モジュールはモデルをトレーニングし、トレーニングされたモデルをオンライン推論モジュールに提供します。オンライン推論モジュールは、トレーニング済みのモデルを TensorFlow サービングなどのサービング システムに読み込みます。クリティカル パス内の他の AI 関連以外のモジュールと連携することで、エンドツーエンドのアプリケーション ベンチマークが構築されます。

大規模なクラスターへの容易なデプロイメントを可能にするために、フレームワークは、それぞれ Ansible と Kubernetes を使用した 2 つの自動デプロイメント テンプレートを含むデプロイメント ツールも提供します。その中で、Ansible テンプレートは物理マシンまたは仮想マシンへのスケーラブルなデプロイメントをサポートし、Kubernetes テンプレートはコンテナ クラスターへのデプロイメントに使用されます。

2.2 AIの問題領域の強調

インターネット サービスにおける幅広い主要な AI 問題領域をカバーするために、著者らは、表 2 に示すように、検索エンジン、ソーシャル ネットワーク、電子商取引という 3 つの主要なインターネット サービスのコア シナリオを詳細に分析しました。合計 16 の代表的な AI 問題領域が特定されました。

表2: インターネットサービスにおけるAIの顕著な問題領域

分類:入力データからさまざまな主題クラスを抽出することは、一連のターゲット カテゴリを定義し、それらを認識するようにモデルをトレーニングすることによる教師あり学習の問題です。これは、インターネット サービスやその他のアプリケーション分野における典型的なタスクであり、カテゴリ予測やスパム検出などのさまざまなシナリオで広く使用されています。

画像生成:データの分布をモデル化し、画像を生成するための教師なし学習問題を提供します。このタスクの一般的なシナリオには、高解像度の画像を生成するために使用できる画像解像度の向上が含まれます。

テキストからテキストへの翻訳:ある言語から別の言語へのテキストの翻訳は、計算言語学の最も重要な分野の 1 つであり、検索や会話をインテリジェントに翻訳するために使用できます。

画像からテキスト:画像の説明を自動的に生成します。画像のキャプションを生成したり、画像内の光学文字を認識したりするために使用できます。

画像から画像へ:画像をある表現から別の表現に変換します。さまざまな年齢の人の顔画像を合成し、仮想メイクをシミュレートするために使用できます。 Face Aging は、さまざまな年齢の顔を検索するのに役立ちます。

音声認識:音声入力を認識してテキストに変換します。このタスクは主に音声検索や音声会話翻訳に使用されます。

顔埋め込み表現:顔画像を埋め込み空間内のベクトルに変換します。このタスクの典型的なシナリオは、顔の類似性分析と顔認識です。

3D 顔認識:さまざまな角度からの複数の画像から 3D 顔情報を識別します。主な研究は 3 次元画像に関するもので、顔の類似性や顔認証のシナリオの実現に役立ちます。

オブジェクト検出:画像内のオブジェクトを検出します。典型的なシナリオは、コンテンツベースの画像検索やビデオオブジェクトの検出などの垂直検索です。

推奨:アドバイスを提供します。このタスクは、広告の推奨、コミュニティの推奨、製品の推奨に広く使用されています。ビデオ予測: 以前のフレームの変換を予測することで、将来のビデオ フレームを予測します。一般的なアプリケーション シナリオは、効率的なビデオの保存と送信のためのビデオ圧縮とビデオ エンコードです。

画像圧縮:画像を圧縮して冗長性を削減します。このタスクは、データ ストレージのオーバーヘッドとデータ転送の効率の観点から、インターネット サービスにとって非常に重要です。

3D オブジェクトの再構築: 3D オブジェクトの予測と再構築。一般的なアプリケーションシナリオには、マップ検索、ライトフィールドレンダリング、仮想現実などがあります。

テキストの要約:テキストの要約を生成することは、検索結果のプレビュー、タイトルの生成、キーワードの検出にとって非常に重要です。

SpatialTransform:空間変換を実行します。典型的なアプリケーション シナリオは、空間的に不変な画像検索です。これにより、画像が大幅に引き伸ばされた場合でも画像を取得できます。

ランク付けの学習:検索コンテンツの特性を学習し、検索結果のスコアをランク付けすることが、検索サービスの鍵となります。

2.3 マイクロベンチマークとコンポーネントベンチマーク

上記で要約した主要な AI の問題に応えて、著者は AI アルゴリズムの具体的な実装を示します。表 3 と 4 に、AIBench のコンポーネント ベンチマークとマイクロベンチマークを示します。 AIBench には、AI 問題に対する 16 個のコンポーネント ベンチマークと、一般的な AI アルゴリズムから計算単位を抽出する 12 個のマイクロベンチマークが含まれています。

表3: AIBenchコンポーネントベンチマーク

表4: AIBenchマイクロベンチマーク

2.4 データモデル

さまざまなアプリケーションのデータセットの多様性に対応するために、著者らは、ImageNet、CIFAR、LSUN、WMT English-German、CityScapes、Librispeech、Microsoft Coco、LFW、VGFace2、Robot Pushing、MovieLens、ShapeNet、Gigaword、MNIST、Gowalla、業界パートナーからの 3D 顔認識データセットなど、15 の代表的なデータセットを収集しました。

2.5 評価指標

AIBench は、精度、パフォーマンス、エネルギー消費などの業界に特化した指標に重点を置いています。オンライン推論のメトリックには、クエリ応答のレイテンシ、テールレイテンシ、スループット、推論の精度、推論のエネルギー消費などのパフォーマンスの側面が含まれます。オフライン トレーニングのメトリックには、1 秒あたりに処理されるサンプル数、特定のエポックのトレーニング時間、目標精度までのトレーニング時間、目標精度までのトレーニングにかかる​​エネルギー消費量が含まれます。

3. アプリケーションベンチマークの設計と実装

著者らは、AIBench フレームワークに基づいて、初のエンドツーエンドの AI アプリケーション ベンチマークを実装し、現実的な電子商取引検索タスクの完全なユースケース モデリングを実行しました。

3.1 設計と実装

エンドツーエンドのアプリケーション ベンチマークは、図 2 に示すように、オンライン サーバー、オフライン アナライザー、クエリ ジェネレーター、データ ストレージの 4 つのモジュールで構成されています。

図2: AIBenchの実装

オンライン サーバーはクエリ要求を受信し、AI 推論を組み合わせてパーソナライズされた検索と推奨を実行します。

オフライン アナライザーは適切な AI アルゴリズムの実装を選択し、トレーニングを実行して学習モデルを生成します。さらに、オフライン アナライザーは、データ アクセスを高速化するためのデータ インデックスの構築も担当します。

クエリ ジェネレーターは同時ユーザーをシミュレートし、特定の構成に従ってオンライン サーバーにクエリ要求を送信します。著者は JMeter ベースのクエリ ビルダーを実装しました。

データ ストレージ モジュールには、構造化データ、非構造化データ、半構造化データなどのさまざまなデータのほか、表、テキスト、画像、オーディオ、ビデオなどのさまざまなデータ ソースが保存されます。

3.1.1 オンラインサーバー

オンライン サーバーは、従来の機械学習とディープラーニングの技術を組み合わせて、パーソナライズされた検索と推奨事項を提供します。オンライン サーバーは、検索プランナー、レコメンダー、サーチャー、ランカーの 4 つのサブモジュールで構成されています。

Search Planer はオンライン サーバーへのエントリ ポイントです。クエリ ビルダーからのクエリ要求を受信し、その要求を他のオンライン コンポーネントに送信し、返された結果を受信する役割を担います。著者は、Spring Boot フレームワークを使用して検索プランナーを実装します。

レコメンダーは、ユーザー データベースから取得したユーザー情報に基づいてクエリ項目を分析し、パーソナライズされた推奨事項を提供します。著者は、Flask Web フレームワークと Nginx を使用してカテゴリ予測レコメンダーを構築し、TensorFlow を採用してオンライン推奨を実装します。

検索ツールは 3 つの異なるクラスターに展開されます。クリック率と購入率に基づいて、製品は人気に応じて 3 つのカテゴリに分類できます。人気の異なる製品のインデックスは、異なるクラスターに保存されます。カテゴリごとに、検索者は異なる展開戦略を採用します。人気の高いクラスターにはより多くのノードとバックアップが含まれており、検索効率が確保されます。あまり人気のないクラスターは、最小限の数のノードとバックアップで展開されます。著者は Elasticsearch を使用して 3 つの検索クラスターを構築および管理します。

ランカーは、レコメンダーによって返された重みを初期重みとして使用し、パーソナライズされた L2R ニューラル ネットワークを通じて製品スコアをランク付けします。ソーターは、Elasticsearch を使用して製品の並べ替えも実装します。

オンラインサービスのプロセスは次のとおりです。

（１）クエリジェネレータは同時ユーザーをシミュレートし、クエリ要求を検索プランナに送信します。

（２）検索プランナーはクエリ要求を受け取り、クエリ用語をレコメンダーに送信する。

（３）レコメンダーはクエリを分析し、カテゴリ予測結果とパーソナライズされた属性の重みを検索プランナーに返します。

（４）検索プランナーは、初期の検索用語と予測分類結果を検索者に送信する。

（５）検索エンジンは転置インデックスを検索し、商品IDを検索プランナに返す。

（６）検索プランナーは、商品IDとパーソナライズされた属性の重みをソーターに送信します。

（７）ソーターは初期重みに従って製品をソートし、ソートスコアを検索プランナーに返す。

（８）検索プランナーは、商品識別子に基づいて商品データベースアクセス要求を送信し、商品情報を取得する。

（９）検索プランナは検索された製品情報をクエリジェネレータに返す。

3.1.2 オフラインアナライザー

オフライン アナライザーは、オンライン サービスのパフォーマンスを向上させるために、モデルのトレーニングとインデックスの構築を担当します。 AI トレーナー、ジョブ スケジューラ、インデクサーの 3 つの部分で構成されます。

AI トレーナーは、データベースに保存されている関連データを使用してモデルをトレーニングします。

ジョブ スケジューラは、バッチ処理とストリーミング処理という 2 つのトレーニング メカニズムを提供します。実際のシナリオでは、一部のモデルは頻繁に更新する必要があります。たとえば、アイテムを検索して最初のページに表示された製品の 1 つをクリックすると、アプリケーションはクリックした製品に基づいて新しいモデルをすぐにトレーニングし、2 ページ目に新しい推奨事項を表示します。このベースライン実装では、この状況を考慮し、ストリーミング アプローチを採用して、数秒ごとにモデルを更新します。バッチ処理の場合、トレーナーは数時間ごとにモデルを更新します。

インデクサーは、製品情報のインデックスを構築するために使用されます。

3.2 他の業界アプリケーションへの拡張性

著者は、医療用人工知能のシナリオを例に、AIBench フレームワークを使用して臨床診断アプリケーションのエンドツーエンドのベンチマークを構築する方法を紹介しました。 AI関連の臨床診断のクリティカルパスには、次のステップが含まれます。

1) 検出モデル、分類モデル、推奨モデルなど、病歴データに基づく一連の診断モデルのオフライントレーニング。

2) CT画像における腫瘍の検出など、患者の身体検査データ内の異常な情報を検出します。

3) 潜在的な疾患の分類と予測

4)適切な治療オプションを推奨します。

エンドツーエンドの臨床診断アプリケーション ベンチマークを構築するために、AIBench フレームワークは AI 関連のオフライン モジュールとオンライン モジュールを柔軟に提供します。オフライン モジュールでは、オブジェクトの検出、分類、推奨のコンポーネント ベンチマークがトレーニング モデルとして選択されます。オンライン モジュールでは、これらのモデルはオンライン推論のサービスとして読み込まれます。

4. 実験のセットアップ

4.1 ノード構成

著者らは 16 ノードの CPU および GPU クラスターを導入しました。 CPU クラスターの場合、すべてのノードは 1GB イーサネット ネットワークに接続されます。各ノードには、2 つの Xeon E5645 プロセッサと 32 GB のメモリが搭載されています。各プロセッサには 6 つのコアが含まれています。各ノードのオペレーティング システムのバージョンは Linux CentOS 6.9、Linux カーネルのバージョンは 3.11.10 です。ソフトウェアのバージョンはそれぞれ JDK1.8.0、Python3.6.8、GCC 5.4 です。 GPU ノードには 4 つの Nvidia Titan XP が搭載されています。各 Titan XP には 3840 個の Nvidia Cuda コアと 12 GB のメモリが搭載されています。表 5 に各ノードの詳細なハードウェア構成を示します。

表5: ハードウェア設定の詳細

4.2 ベンチマーク展開

オンライン サーバーのセットアップ:オンライン サーバーは、16 ノードの CPU クラスターにデプロイされます。これには、クエリ ビルダー ノード 1 つ、検索プランナー ノード 1 つ、レコメンダー ノード 2 つ、サーチャー ノード 9 つ、ソーター ノード 1 つ、およびデータ ストレージ ノード 2 つが含まれます。表 6 に、詳細なモジュール設定情報と関連するソフトウェアを示します。

表6: オンラインサーバーの設定

オフライン トレーナーのセットアップ:オフライン トレーナーは GPU にデプロイされます。 CUDA および Nvidia ドライバーのバージョンはそれぞれ 10.0 と 410.78 であり、PyTorch 実装のバージョン 1.1.0 が使用されます。

4.3 パフォーマンスデータの収集

著者らは、ネットワーク タイム プロトコルを使用して、すべてのクラスター ノード間でクロックを同期し、オンライン サーバーのレイテンシとテール レイテンシのメトリックを取得します。分析ツール Perf を使用して、ハードウェア パフォーマンス監視カウンター (PMC) を通じて CPU マイクロアーキテクチャ データを収集します。 GPU プロファイリングでは、著者らは Nvidia プロファイリング ツールキット nvprof を使用して GPU のパフォーマンスを追跡しました。

5. 評価

著者らは、オンライン サーバーやオフライン アナライザーなど、エンドツーエンドの AI アプリケーション ベンチマークに含まれる 10 個の AI コンポーネント ベンチマークを評価しました。

5.1 オンラインサーバー評価

著者らは、16 ノードの CPU クラスター上でオンライン サーバーのパフォーマンスを評価しました。製品データベースには、32 個の属性フィールドを持つ 100,000 個の製品が含まれています。クエリ ビルダーは、30 秒のウォームアップ時間で 1,000 人のユーザーをシミュレートします。ユーザーは、ポアソン分布に従って、各思考時間間隔内でクエリ要求を継続的に送信します。 20,000 件のクエリ要求が完了すると、パフォーマンス データが収集されます。

図3: オンラインサーバーのレイテンシ

レイテンシはサービス品質を測定するための重要な指標です。図 3 はオンライン サーバーのレイテンシを示しています。図 3(a) に示すように、現在のベンチマーク実装の実行パス全体の合計レイテンシの平均、90 パーセンタイル、99 パーセンタイルは、それぞれ 161.13 ミリ秒、392 ミリ秒、956 ミリ秒です。著者らは、各モジュールのレイテンシをさらに詳細に分析し (図 3b)、レコメンダーのレイテンシが最も大きいことを発見しました。平均レイテンシは 75.7 ミリ秒、90 パーセンタイル レイテンシは 209.4 ミリ秒、99 パーセンタイル レイテンシは 557.7 ミリ秒でした。比較すると、検索および推奨リクエストのレイテンシは 4 ミリ秒以内です。

さらに、図3(c)は、クエリ解析、ユーザーデータベースアクセス、カテゴリ予測、TensorFlowサービングの観点から見たレコメンダーのレイテンシの内訳を示しています。著者らは、データベース アクセスと TensorFlow サービングのレイテンシが、サービング パフォーマンスに影響を与える上位 2 つの要因であることを発見しました。複雑なデータ構造と頻繁なガベージコレクションは、データ アクセス速度に大きな影響を与えます。一方、TensorFlow Serving では、前向き推論に推奨モデルを使用する必要があり、その結果、レイテンシが大きくなります。 AI コンポーネントがサービス パフォーマンスに与える影響を測定し、ボトルネックを特定するために、著者らは以下の側面について議論しました。

AI 関連コンポーネントがサービス パフォーマンスに与える影響の重み。 AIコンポーネントによりクリティカルパスが大幅に変更されます。評価では、AI 関連コンポーネントと AI 非関連コンポーネントに費やされた時間の平均は 34.29 ミリ秒と 49.07 ミリ秒、90 パーセンタイルのレイテンシは 74.8 ミリ秒と 135.7 ミリ秒、99 パーセンタイルのレイテンシは 152.2 ミリ秒と 466.5 ミリ秒でした。これは、産業規模の AI アプリケーションのベンチマーク スイートが現代のインターネット サービスに不可欠であることを示しています。

AIの限界。 オンライン推論モジュールは、結果を取得するためにトレーニング済みのモデルを読み込み、順方向計算を実行する必要があります。ただし、ニューラル ネットワーク モデルの深さやサイズは推論時間に大きな影響を与える可能性があります。モデル サイズが 184 MB から 253 MB に増加すると、TensorFlow Serving のレイテンシが大幅に増加し、平均レイテンシは 30.78 ミリ秒から 125.71 ミリ秒に増加し、99 パーセンタイル レイテンシは 149.12 ミリ秒から 5335.12 ミリ秒に増加します。したがって、インターネット サービス アーキテクトは、サービス品質とニューラル ネットワーク モデルの深さまたはサイズとの間でトレードオフを行う必要があります。

微細構造挙動の違い:

• AI に関連しないコンポーネントと AI に関連するコンポーネントの違い。著者らは perf を使用して、AI 関連コンポーネントと AI に関連しないコンポーネントのキャッシュ動作をサンプリングしました。著者らは、AI 関連コンポーネントは AI 関連以外のコンポーネントよりもキャッシュ ミスが多く発生することを発見しました。 TensorFlow Serving では 1,000 命令あたり 61 回の L2 キャッシュ ミスが発生しましたが、AI に関連しないコンポーネントの平均はわずか 37 回でした。
• 小規模ニューラル ネットワーク モデルから大規模ニューラル ネットワーク モデルへの変更。著者らは、184MB と小さいモデルと 253MB と大きいモデルの 2 つのニューラル ネットワーク モデルを比較しました。より大きなモデルの場合、1000 命令あたりの L3 キャッシュ ミス率が 1.38 から 8.9 に大幅に増加し、メモリからデータを取得するためにメモリ バックエンドが大量に停止する原因となります。その結果、99 パーセンタイルのレイテンシは 30 倍以上増加しました。

5.2 オフライントレーニング評価

このサブセクションでは、主に GPU の実行効率を分析し、Titan XP 上のエンドツーエンド AI アプリケーション ベンチマークのオフライン プロファイラーで使用される 10 個のコンポーネント ベンチマークを評価します。

著者らは、関数レベルのランタイム分解と実行一時停止分析を通じて、GPU の動作効率を包括的に分析します。図 4 は、各コンポーネント ベンチマークの SM 効率を示しており、29% (ランク付けの学習) から 95% (推奨) の範囲です。

図4: SM効率

パフォーマンスに影響を与える要因を調査するために、著者らはまず実行時分解分析を実行してベンチマークをホットスポット カーネルまたは関数に分解し、次にさまざまな一時停止率に基づいて GPU 実行効率を計算します。

5.2.1 実行時間の内訳

著者は nvprof を使用して実行時間を追跡し、実行時間の 80% 以上を占めるホット関数を見つけます。著者らは、実行時間の長い関数を選択し、計算ロジックに応じてカーネルのいくつかのカテゴリに分類しました。 10 個のコンポーネント ベンチマークの中で最も時間のかかる関数を、畳み込み、一般的な行列乗算 (gemm)、バッチ正規化、relu 活性化関数、要素ごとの演算、勾配計算の 6 つのカーネル カテゴリに統計的に分類します。各カーネルには、同様の問題を解決する一連の関数が含まれています。たとえば、gemm カーネルには、単精度または倍精度浮動小数点の一般的な行列乗算などが含まれています。図 5 は、上記の 6 つのカーネルの実行時間の内訳を、各カーネルのすべての関連関数の平均として示しています。

図5: 10個のコンポーネントベンチマークの実行時間の内訳

さらに、著者は各カーネルについて、10 個のコンポーネント ベンチマークで実行時間の長い典型的な関数をまとめています (表 7 を参照)。

表7: 各カーネルのホット関数

図 5 から、ランク付けの学習では畳み込みに時間がかかりすぎていることがわかります。対応する関数呼び出しは maxwell_scudnn_128x32_stridedB_splitK_interior_nn で、SM 効率は 18.5% です。これが、ランク付けの学習ベンチマークの SM 効率が最も低い理由です。著者らは、これら 6 つのカーネルとそれに対応する関数は、CUDA ライブラリの最適化の最適化方向であるだけでなく、マイクロアーキテクチャの最適化の最適化方向でもあると考えています。

5.2.2 GPU実行効率分析

上記の最も時間のかかる 6 つのカーネルについて、著者らは、命令フェッチ一時停止 (Inst_fetch)、実行依存一時停止 (Exe_depend)、メモリ依存一時停止 (M​​em_dependent)、テクスチャ一時停止 (Texture)、同期一時停止 (Sync)、定数メモリ依存一時停止 (Const_mem_depend)、パイプライン ビジー一時停止 (Pipi_busy)、およびメモリ制限一時停止 (M​​em_throttle) の 8 種類の一時停止を評価しました。

図6: コアごとの一時停止の内訳

図 6 は、各コアの 8 種類の一時停止の内訳を示しています。著者らは、GPU 実行ストールの上位 2 つは、メモリ依存ストールと実行依存ストールであることを発見しました。メモリ依存性の停止はキャッシュミスが原因である可能性があり、そのためロード/ストア リソースは使用できません。最適化戦略には、データの配置、データの局所性、およびデータ アクセス パターンの最適化が含まれます。命令レベルの並列性が低いため、実行依存関係の停止が発生する場合があります。そのため、ILP を利用すると、実行依存関係の停止をある程度軽減できます。

著者らは、関数呼び出しの潜在的な最適化ガイダンスを提供するために、表 7 で関数レベルの一時停止も特定しています。たとえば、「Convolution」クラスの maxwell_scudnn_128x32_stridedB_splitK_interior_nn 関数のメモリ依存ストール率は 61% に達しますが、「GEMM」クラスの maxwell_sgemm_128x64_nn 関数のメモリ依存ストール率は 18% であり、パフォーマンスを最大限に向上させるには異なる最適化戦略が必要であることがわかります。

結論は

本稿では、中国企業 17 社が共同で立ち上げた初の業界標準インターネット サービス AI ベンチマーク スイートを紹介します。著者らは、拡張性、構成性、柔軟性に優れた AI ベンチマーク フレームワークを提案および実装し、最も重要な 3 つのインターネット サービス ドメイン (検索エンジン、ソーシャル ネットワーク、電子商取引) から 16 の主要な AI 問題領域を抽出しました。 AIBench フレームワークに基づいて、初のエンドツーエンドのインターネット サービス AI ベンチマーク スイートが設計および実装され、基盤となる電子商取引検索モデルが提供されました。著者らは、CPU および GPU クラスター上のエンドツーエンドのアプリケーション ベンチマークの予備評価を実行します。 AI 関連コンポーネントは、インターネット サービスのクリティカル パスとワークロード特性を大幅に変更し、エンドツーエンドの AI アプリケーション ベンチマークの正確性と必要性​​を証明します。