ディープラーニングモデルのサイズとモデル推論速度に関するいくつかの議論

[[426034]]

この記事では、計算量、パラメータ数、メモリアクセス量、メモリ使用量など、ディープラーニング モデルのサイズを測定するために一般的に使用されるいくつかの指標について説明します。これらの指標がモデルの展開と推論に与える影響、特に計算量とメモリアクセス量がモデルの推論速度に与える影響を分析し、さまざまなハードウェア アーキテクチャでのネットワーク構造の設計に関する提案をいくつか示します。

0. はじめに

私がアルゴリズムに取り組む最初のインターンシップをしていたとき、上司から最初に与えられた課題は「大きなセグメンテーション モデルを小さなモデルに分割する」というものでした。当時は「大きい」モデルや「小さい」モデルの本当の意味を理解していなかったため、単純に計算量を評価指標として選択し、狂ったように計算量を削減し（バックボーンをMobileNet/ShuffleNetに置き換え、ConvをDepthWise Convに置き換え、奇妙な融合構造をいくつか採用するなど）、モデルの計算量を10倍近く削減しました。その結果、デプロイ後も速度はそれほど速くならないことがわかりました。それどころか、元のResNetのブロックを数個切り捨てた方が効果は高かったです。

また、インベントリアクセス、パイプライン、RoofLineモデルなどの概念に触れ、モデルの推論速度の問題に興味を持つようになったのもこの頃からでした。そこから、ディープラーニングの推論最適化の道へと進みました（取り消し線）。

私はしばらくの間、推論の最適化と HPC に取り組んできましたが、推論を理解しておらず、ハードウェアと大きく一致していなかったときに設計したモデルを今でも時々思い出します。また、職場で研究者とコミュニケーションをとると、モデルのサイズとモデル推論速度の関係を理解し​​ていない研究者がいて、ハードウェアの計算能力を十分に活用することが難しいモデル構造を設計していることもわかりました。そこで、この記事では、計算量、パラメータ数、メモリアクセス量、メモリ使用量など、モデルのサイズを評価するために使用されるいくつかの指標について詳しく説明します。また、これらの指標がモデルの展開と推論に与える影響を分析し、計算量とメモリアクセス量がモデルの推論速度に与える影響について詳しく説明します。また、さまざまなハードウェアアーキテクチャで効率的なネットワーク構造を設計するための提案もいくつか示します。

この記事は、ネットワーク設計の提案を提供するだけでなく、パフォーマンス最適化の基本的な理論的知識とパフォーマンス分析の基本的な考え方を効果的に伝え、学生がネットワーク設計と展開のギャップを減らし、ネットワーク設計と展開をより効率的に完了できるようにすることを目的としています。この記事が皆さんの仕事に役立つことを心から願っています。また、ディスカッションのためにコメント欄にコメントを残していただければ幸いです。

1. 一般的に使用されるモデルサイズ評価指標

現在、モデルのサイズを評価するために一般的に使用される指標には、計算の複雑さ、パラメータの数、メモリ アクセス、メモリ使用量などがあります。これらの指標は、さまざまな次元からモデルのサイズを評価します。このセクションは簡単な紹介に過ぎません。すでにご存知の方は、このセクションをスキップして、以下の分析と議論に直接進んでください。

1. 計算量

計算量は、モデルのサイズを評価するために最も一般的に使用される指標であると言えます。多くの論文では、ベースラインと比較する際に計算量を重要な比較基準として使用しています。

計算量とは、モデルに必要な計算回数であり、モデルのハードウェア計算ユニットに対する需要を反映します。計算量は一般的にOP （Operations）、つまり計算回数で表されます。最も一般的に使用されるデータ形式は float32 であるため、浮動小数点演算の回数を意味するFLOP (Floating Point Operations) と表記されることが多いです。 （従来の慣習に合わせるため、以下のテキストでは FLOP を使用します）

モデルの全体的な計算量は、モデル内の各演算子の計算量の合計に等しくなります。ただし、各演算子の計算量の計算方法は異なります。たとえば、Eltwise Sum の場合、サイズ (N、C、H、W) の 2 つのテンソルの加算には、N x C x H x W の計算が必要です。畳み込みの場合、計算式は次のようになります (乗算と加算はそれぞれ 1 回ずつ計算されます)。

PyTorch には計算量をモデル化できるツールが多数ありますが、これらのツールは一部の演算子の計算を見逃してその計算を 0 としてカウントする可能性があり、その結果、統計計算と実際の計算の間にわずかな偏差が生じることに注意してください。ただし、ほとんどの場合、これらの偏差はほとんど影響しません。

2. パラメータ量

初期の論文では、モデルのサイズを評価するためにパラメータの数を使用することも好まれていました。

パラメータ数はモデル内のパラメータの合計であり、モデルがディスク上で必要とするスペースの量に直接関係します。 CNN の場合、パラメータは主に Conv/FC 層の重みで構成されます。もちろん、他の演算子にもパラメータがありますが、通常は無視できます。

パラメータの数はメモリアクセス量の一部としてカウントされることが多いため、パラメータの数はモデル推論のパフォーマンスに直接影響しません。ただし、パラメータの数は、一方ではメモリ使用量に影響し、他方ではプログラムの初期化にかかる時間に影響します。

パラメータの数はパッケージのサイズに直接影響します。ソフトウェア パッケージのサイズが重要な指標である場合、パラメータの数は非常に重要です。たとえば、モバイル APP シナリオでは、APK パッケージのサイズに厳しい制限があることがよくあります。また、一部の組み込みデバイスではフラッシュ スペースが非常に小さいです。モデル ディスクに多くのスペースが必要な場合は、収まらない可能性があるため、パラメータの数にも要件があります。

モデルを設計する際のパラメータの数を減らすだけでなく、モデルを圧縮することでソフトウェア パッケージのサイズも削減できます。たとえば、Caffe や ONNX で使用される Protobuf は、モデルを効率的にエンコードおよび圧縮できます。ただし、圧縮モデルでは解凍のオーバーヘッドが発生し、プログラムの初期化時間がある程度長くなります。

3. 在庫にアクセスする

アクセス量は、最も見落とされやすい評価指標であることが多いですが、実際には現在のコンピューティング アーキテクチャのパフォーマンスに大きな影響を与える指標です。

メモリ アクセス量とは、モデル計算中にアクセスする必要があるストレージ ユニットのバイト サイズを指し、ストレージ ユニットの帯域幅に対するモデルの要求を反映します。アクセスされるデータの量は通常、バイト(またはKB/MB/GB ) で表されます。これは、モデルが計算のために保存/アクセスする必要があるデータのバイト数を意味します。

計算量と同様に、モデルによってアクセスされるメモリの合計量は、モデル内の各演算子によってアクセスされるメモリ量の合計に等しくなります。 Eltwise Sum の場合、サイズ (N、C、H、W) の 2 つのテンソルを追加すると、メモリ アクセスは (2 + 1) x N x C x H x W x sizeof(data_type) になります。ここで、2 は 2 つのテンソルの読み取りを表し、1 は 1 つのテンソルの書き込みを表します。畳み込みの場合、メモリ アクセスの式は次のようになります。

モデルへのアクセス量はモデルの推論速度にとって非常に重要であり、モデルを設計する際に考慮する必要があります。

4. メモリ使用量

メモリ使用量は、モデルの実行時に占有されるメモリ/ビデオ メモリの量を指します。一般的に、最大メモリ使用量はエンジニアリング上重要です。もちろん、平均メモリ使用量が使用されるシナリオもあります。ここで注意すべき点は、メモリ使用量 ≠ アクセス メモリではないということです。

メモリ使用量は、そのサイズがモデル自体だけでなくソフトウェア実装によっても影響を受けるため、論文ではあまり使用されません。たとえば、推論速度を確保するために、一部のフレームワークではモデル内の各テンソルに必要なメモリを事前に割り当て、メモリ使用量はネットワーク内のすべてのテンソルのサイズの合計になります。ただし、より多くのフレームワークがライト メモリ モードを提供し、テンソルにメモリを動的に割り当ててメモリ使用量を最大限に節約します (もちろん、パフォーマンスが多少犠牲になる場合があります)。

パラメータ数と同様に、メモリ使用量は推論速度に直接影響せず、メモリアクセス量の一部としてカウントされることが多いです。しかし、推論サーバー、車載プラットフォーム、携帯電話アプリなど、同じプラットフォーム上で複数のタスクが同時に実行される環境では、メモリ使用量を制御できることが求められることがよくあります。一方、制御可能とは、使用されるメモリ/ビデオメモリの量を指します。多すぎると、プラットフォーム上で他のタスクを実行できなくなります。一方、使用されるメモリ/ビデオメモリの量が大きく変動せず、他のタスクの可用性に影響を与えないことを意味します。

5. まとめ

計算量、パラメータ数、メモリアクセス量、メモリ使用量は、さまざまな次元からモデルのサイズを定義するため、さまざまな状況に応じて適切な指標を選択して評価する必要があります。

モデル推論速度は、モデルの計算量だけでなく、メモリアクセス量やその他のいくつかの要因にも密接に関連しています。モデル推論速度に影響を与える要因については、以下で詳しく説明します。

2. 計算量が少ないほど、モデル推論は速くなりますか?

答えはノーです。

実際のところ、計算量と実際の推論速度の間には直接的な因果関係はありません。計算量は、モデル推論の速度の参考としてのみ役立ちます。

特定のハードウェア上でのモデルの推論速度は、計算量だけでなく、アクセス量、ハードウェア特性、ソフトウェア実装、システム環境など多くの要因によって影響を受け、複雑な特性を示します。したがって、手元にハードウェアがあり、テストが便利な場合は、実際のテストがパフォーマンスを評価する最も正確な方法です。

ネットワーク構造を設計する際、条件が許せば、モデル反復の初期段階でパフォーマンスをテストすることをお勧めします。一部の NAS メソッドでは、検索対象のネットワーク構造の速度もテストしたり、初期検索の重要なパラメータとしてハードウェア速度を単純にモデル化したりします。この方法で設計されたネットワークは、後の展開時にパフォーマンスの問題によって発生する反復的な最適化の時間と人的コストを大幅に削減します。

ここでは、ハードウェア上のモデルの推論速度に影響を与えるいくつかの要因について説明します。一方では、手動/自動でネットワーク構造を設計する学生が、より効率的なネットワーク構造をより速く設計できるように支援したいと考えています。他方では、モデルの展開中にパフォーマンスの問題が発生した場合の原因を分析するためのアイデアを提供したいと考えています。

この問題について、次の3つの点から議論したいと思います。

• 密度とルーフラインモデルの計算

• 計算集約型演算子とメモリ集約型演算子

• 推論の時間

1. 密度とRoofLineモデルの計算

計算密度とは、メモリ アクセス単位あたりのプログラムに必要な計算量を指し、単位は FLOP/バイトです。計算式は非常に簡単です。多くの教科書や資料では計算アクセス比率とも呼ばれています。これは、メモリアクセスに対するプログラムの計算強度を反映するために使用されます。

RoofLine モデルは、プログラムがハードウェア上で達成できるパフォーマンスの上限を評価するために使用されるモデルであり、次の図で表すことができます。

ルーフラインモデル

式で説明すると:

プログラムの計算密度 Iが小さい場合、プログラムはより多くのメモリにアクセスしますが、計算は少なくなり、パフォーマンスはメモリ帯域幅によって制限されます。これはメモリ集約型プログラムと呼ばれ、図のオレンジ色の領域です。この領域におけるプログラム パフォーマンスの上限 = コンピューティング密度 × メモリ帯域幅で、図では対角線で表され、傾きはメモリ帯域幅のサイズです。計算密度が高くなるほど、プログラムが達成できる速度の上限は高くなりますが、使用されるメモリ帯域幅は常に最大値になります。

逆に、計算密度Iが大きい場合、プログラム性能はハードウェアの最大計算ピーク（以下、計算能力と呼ぶ）によって制限され、図の青い領域が計算集約型プログラムと呼ばれる。このとき、性能の上限＝ハードウェアの計算能力となり、図では水平線で表されます。このとき、計算速度は計算密度の影響を受けませんが、計算密度が高くなるほど、必要なメモリ帯域幅は少なくなります。

2 本の線の交点では、計算速度とメモリ帯域幅の両方が最大値に達します。

同じプログラムのプロパティはデバイスによって変わる場合があります

同じプログラムのプロパティは、デバイスによって異なる場合があります。たとえば、上の図のプログラム 2 は、計算能力が弱いデバイス 2 では計算集約型のプログラムですが、計算能力が強いデバイス 1 ではメモリ集約型のプログラムです (コメント セクションでの訂正に感謝します)。デバイス 1 の性能をフルに活用したい場合は、プログラムの計算密度を適切に (たとえば、プログラム 3 の位置まで) 上げる必要があります。

2. 計算集約型演算子とメモリ集約型演算子

ネットワーク内の演算子は、計算密度に応じて分類できます。一般的に言えば、Conv、FC、および Deconv 演算子は計算集約型の演算子であり、ReLU、EltWise Add、Concat などはメモリ集約型の演算子です。

同じ演算子でも、パラメータが異なると計算密度やプロパティが異なる場合があります。たとえば、他のパラメータが変更されていない場合、Conv グループを増やすか、Conv 入力チャネルを減らすと、計算密度が低下します。

たとえば、異なるパラメータを使用した畳み込みの場合、密度は次のように計算されます。

畳み込み演算子の計算密度は、パラメータによって大きく異なることがわかります。 4 番目の演算子である Depthwise Conv の計算密度はわずか 2.346 であり、これは現在の多くのデバイスではメモリを大量に消費する演算子です。

演算子の計算密度が高くなるほど、ハードウェアの計算効率が向上し、ハードウェアのパフォーマンスが最大限に発揮される可能性が高くなります。例として、Intel X86 サーバー プラットフォーム (10980 XE) を取り上げます。このプラットフォームの CPU 周波数は 4.5 GHz です。16 コアを例にとると、理論上の FP32 コンピューティング能力は 4.608 TFLOPs/s、理論上のメモリ帯域幅は 96 GB/s です。このプラットフォーム上の RoofLine モデルは次のとおりです。

Intel 10980 XE 16コアルーフラインモデル、および各演算子の計算密度とパフォーマンス

プラットフォームの「変曲点」の計算密度は48です。より計算集約的なOP1とOP2は計算集約領域にあり、プラットフォームのピーク計算能力に到達できます。一方、OP3とOP4はメモリアクセス集約領域にあり、メモリ帯域幅の制限により計算能力のピークに到達できません。特にOP4は計算メモリアクセス率が低いため、計算効率はわずか4.9％と低く、高くありません。

3. 推論の時間

ここにはギャップがあります。多くのデプロイメントの学生は「計算効率」について話すことを好みますが、実際には、アルゴリズムの学生が本当に気にしているのは「推論時間」であり、この 2 つが関連付けられると誤解を招くことがよくあります。そこで、ここでは別のセクションを設けて「推論時間」の評価方法について議論したいと思います。

実際、これも非常に簡単です。RoofLine モデルによれば、演算子の実際の実行時間を簡単に取得できます。

これは区分関数であり、次のように分解できます。

一言でまとめると、メモリを集中的に使用する演算子の場合、推論時間はメモリ アクセスの量に比例しますが、計算を集中的に使用する演算子の場合、推論時間は計算の量に比例します。

この時点で、この章の冒頭の質問に暫定的に答えることができます。RoofLine モデルによれば、計算集約型の領域では、計算量が少ないほど推論時間が短くなります。しかし、メモリを大量に消費する領域では、計算量は推論時間とは関係ありません。本当に重要なのはメモリアクセスの量です。メモリアクセスの量が少ないほど、推論時間は速くなります。全体的に、計算時間と推論時間の間には線形関係はありません。

前のセクションでは、OP4 は計算効率が低いものの、メモリアクセスも少ないため、推論速度は他の OP よりも実際に高速であることがわかりました。しかし、計算の複雑さは OP1 の 1/130 に過ぎないにもかかわらず、推論時間は 1/6 にしか短縮されていないことがわかります。この 2 つは線形関係ではありません (これが、モデルの計算複雑さを 1/10 に削減したが、それほど高速化されなかった理由でもあります)。

これを補強するために、さらに 2 つの例を見てみましょう。まず、次の 2 つの畳み込みを見てみましょう。計算量は似ていますが、どちらもメモリを大量に消費する領域にあるため、OP3 のメモリ アクセス量は OP5 よりもはるかに少なく、推論も高速です。

以下の例はより明白です。OP5 と OP6 の唯一の違いは、一方が DepthWise Conv であり、もう一方が通常の Conv であることです。他のパラメータは変更されません。以前の直感によれば、Conv を DepthWise Conv に置き換えると速くなるはずですが、実際には 2 つの推論時間はほぼ同じです (このパラメータ セットは、当時私が使用していたものでもあります [顔を手動で隠します]):

4. まとめ

以上のことから、モデルの推論時間を評価するには計算量だけでは不十分であることがわかります。総合的な評価を行うには、ハードウェア特性 (計算能力と帯域幅) やメモリ アクセスも考慮する必要があります。計算量が少ないほど、モデルの推論が速くなるというわけではありません。 モデルサイズを評価する際には、アクセスボリュームも重要な評価指標として追加することをお勧めします。

強調する必要がある点の 1 つは、ハードウェア プラットフォームによってピーク時の計算能力とメモリ帯域幅が異なるため、同じモデルでもプラットフォーム 1 では計算集約型になり、プラットフォーム 2 ではメモリ集約型になる可能性があるということです。たとえば、前述の Intel X86 プラットフォームの「変曲点」値は 48 ですが、NVIDIA V100 の「変曲点」値は 173.6 です。上記の例では、V100 プラットフォームの OP2 のみが計算集約型領域に該当し、残りはすべてメモリ集約型です。したがって、同じモデルの特性は異なるプラットフォーム上で変化する可能性があり、ケースバイケースで具体的な分析が必要になります。

RoofLine モデル自体が非線形モデルであるため、一般的な結論を導き出すことは困難です。ここで強調しなければならないのは、ピーク時の計算能力とメモリ帯域幅に加えて、ハードウェアの制限、システム環境、ソフトウェアの実装など、プログラムの実際のパフォーマンスに影響を与える多くの要因があり、その非線形特性がより深刻になるということです。したがって、RoofLine モデルはパフォーマンス評価の上限のみを提供でき、達成できる実際のパフォーマンスを表すものではありません。実際のパフォーマンスを測定する最も正確な方法は、実際のデバイスをテストすることです。

さらに重要なことは、RoofLine モデルはパフォーマンスを分析するためのアイデアを提供します。つまり、計算集約型のプログラムはハードウェアの計算能力によってより制限され、メモリ集約型のプログラムはハードウェアのメモリ帯域幅によってより制限されます。この理解に基づいてネットワーク構造を設計し、ネットワーク パフォーマンスを分析すると、より理論的な参照が得られます。 「計算量は半分になったのに、なぜ推論時間は変わらないのか」という疑問がなくなる（私のことだよ（涙））

以下では、RoofLine モデルのいくつかの制限について説明し、どの要因がプログラムにどのような影響を与え、RoofLine モデルによって推定されたパフォーマンスの上限に到達できない原因となるかを分析します。

(これから難易度が上がっていきます。RoofLine モデルを理解していない学生は、この章をもう一度読むことをお勧めします。そうしないと、後で読むときに少し混乱します。)

3. モデル推論のパフォーマンスに影響を与えるその他の要因

RoofLine モデルはプログラム パフォーマンスの上限を評価するために使用できますが、実際に達成できるパフォーマンスは、ハードウェアの制限、システム環境、ソフトウェアの実装など、多くの要因によっても左右され、パフォーマンスの上限からは依然として一定の距離があります。この章では、これらの影響要因を分析します。

1. ハードウェアの制限がパフォーマンスの上限に与える影響

以前の RoofLine モデルで使用されるピークコンピューティング能力とメモリ帯域幅は、論文データに基づいて計算された理論上の最大値です。しかし、実際の状況では、さまざまな理由により、ハードウェアがこの理論値に到達できない場合があります。したがって、ハードウェアの実際のパフォーマンス上限を取得するには、ハードウェアのマイクロベンチマークを実行することをお勧めします。

前述のIntel X86 CPUを例にとると、先ほど計算したavx512の理論上の演算能力は4.608 TFLOPs/sですが、この値は周波数が4.5GHzを維持できることを前提としています。しかし、実際には、16 個のコアを使用して avx512 命令を実行すると、CPU 周波数は約 2.9 GHz まで低下します。このとき、理論上の計算能力はわずか 2.96 TFLOPs/s ですが、測定値はわずか 2.86 TFLOPs/s です。

周波数に加えて、設計または実装上の理由により、一部のチップは実際の使用時に理論上のピーク値に達しない場合があります。たとえば、一部のローエンド チップは、マルチイシューをサポートしておらず、アウトオブオーダー実行をサポートしておらず、ブロッキング キャッシュなどを使用していません。一部のチップにはパフォーマンス バグがあり、実際の使用では理論上のピークにほとんど到達しません (ここで私は個人的に、これらの理由をハードウェアの制限によって引き起こされる損失に帰する傾向があります)。

メモリについても同様です。プラットフォームの理論上の帯域幅は 96 GB/秒ですが、実際に測定された最大読み取り帯域幅はわずか 74 GB/秒で、理論上の帯域幅の 77% にしか達しません。

修正された RoofLine モデルを取得できます。図の青く塗りつぶされた部分は、実際の計算能力とメモリ帯域幅が理論値に達しないことによって生じる損失を反映しています。

測定されたピークコンピューティング能力とメモリ帯域幅を修正した後の RoofLine モデル。青く塗りつぶされた部分は、ハードウェアの制限によって生じた損失です。

改訂されたモデルの「変曲点」が変更されたため、演算子の特性も変更されます。ハードウェアを入手したら、マイクロベンチマークを実行することをお勧めします。推奨されるテスト ツールは次の 2 つです。

1 つは、Uncle Gao が書いた浮動小数点ピーク テスト方法に関する記事です。最後に github リンクがあります。これをクローンして、ハードウェア ピーク値をテストできます。

メモリ帯域幅をテストするために使用できるストリーム テスト ツールもあります。

2. システム環境がパフォーマンスに与える影響

プログラムがベアメタルマシン上で実行されない限り、複数のコア間のオペレーティングシステムのスケジューリングによる損失、オペレーティングシステムのメモリ管理による損失、オペレーティングシステム自体が占有するコンピューティングリソースなど、オペレーティングシステムはパフォーマンスの上限に確実に一定の影響を与えます。

一般的なディープラーニング推論タスクの場合、最新のオペレーティング システムがパフォーマンスに与える影響は特に明白ではありません。ただし、特殊なケースでは、重大なパフォーマンスの低下につながる可能性もあります。ここで 2 つの例を挙げます。

1 つは、Android システムを大きなコアと小さなコアにスケジュールすることです。プログラムの CPU 使用率が不十分になると (定期的なタスクなど)、Android によって小さなコアにスケジュールされ、パフォーマンスが低下する可能性があります。

もう 1 つの例は、メモリ ページ フォールトです。 Linux システムでは、システムからメモリ ページが要求されると、システムは仮想ページのみを返します。プログラムが実際に仮想ページを使用すると、ページ フォールト例外がトリガーされ、オペレーティング システム カーネルに入り、物理ページが割り当てられます。このプロセスにより、パフォーマンスが大幅に低下します。

幸いなことに、これらの問題はソフトウェアによって部分的に補うことができます。たとえば、スケジューリングの問題はコアをバインドすることで解決でき、ページ欠落の問題は物理ページ (カーネル モードが必要) またはメモリ プールをバインドすることで解決できます。したがって、オペレーティング システムの影響は制御可能です。

オペレーティング システムの影響に加えて、システム内で実行されている他のプロセスも現在のプロセスに影響を与えます。たとえば、システム内で複数のディープラーニングインスタンスが実行されている場合や、一部のアプリがシステムのバックグラウンドで自動的に起動されている場合などです。これらのプロセスはコアコンピューティング能力とメモリ帯域幅を占有し、現在のプロセスのパフォーマンスの低下を引き起こします。

その結果、エンジニアリング テスト環境ではパフォーマンス要件を満たしていたモデルでも、実際に導入するとパフォーマンスが低下することがよくあります。したがって、エンジニアリングテスト環境と実際の展開システム環境の違いに注意する必要があります。条件が許せば、実際の展開環境でテストするのが最適です。

3. ソフトウェア実装がパフォーマンスに与える影響

ハードウェアの制限とシステム環境に加えて、タスクのソフトウェア実装の品質もパフォーマンスに大きな影響を与えます。

たとえば、同じ行列演算タスクの場合、Python で記述された複数の for ループと NumPy の高度に最適化された行列演算関数のパフォーマンスは、1 ～ 2 桁異なる場合があります。

ディープラーニングモデルの推論の場合、推論フレームワークがモデルのパフォーマンスに与える影響は、主に、ハードウェアパイプラインリソースが十分に活用されているかどうか、ハードウェア内のキャッシュが効率的に活用されているかどうか、時間計算量の少ないアルゴリズムが採用されているかどうか、オペレーティングシステムによって引き起こされるパフォーマンスの低下（前述のスケジューリング問題やメモリページフォールト問題など）が解決されているかどうか、正確で効率的なグラフ最適化が実行されているかどうかなどに反映されます。

影響要因が多数あるため、ソフトウェアがパフォーマンスに与える影響は強い非線形性を示すことが多く、パフォーマンスを評価する際に普遍的な結論を導き出すことが困難です。多くの場合、特定の状況しか分析できません。 （時には少し形而上学的です[顔を隠す]）

たとえば、計算量が同じベクトル演算と超越関数の場合、多くのハードウェアが超越関数の SIMD 命令をサポートしていないため、後者は前者よりも遅くなることがよくあります。別の例としては、前者は後者ほど効率的にメモリを使用しないため、拡張畳み込みのパフォーマンスは通常の畳み込みよりも劣る、などがあります。

ソフトウェア実装の影響により、RoofLine モデルの上限は再び下がり、図の赤い線に達します (実際の非線形性は、私が適当に描いたものよりもはるかに複雑である可能性があります)。

RoofLine モデルのさまざまなパフォーマンス損失の概略図。図の曲線は実際のスケールを表すものではありません。

したがって、ディープラーニングの推論パフォーマンスを評価または分析する場合、単純な計算およびメモリアクセスのメトリックではまったく不十分であり、パフォーマンスの上限の参照としてのみ機能します。実際に達成できるパフォーマンスは、演算子のメモリ アクセス モード、データの配置、グラフ融合が可能かどうか、許容できる精度と低い時間計算量を備えたアルゴリズムがあるかどうか、アルゴリズムに十分な並列性があるかどうか、さまざまな操作の割合など、多くの要因に依存します。

これらの要素はアルゴリズムを学ぶ学生にとっては複雑すぎる可能性があり、習得する必要はありません。ただし、会社/部門がコミュニケーションの機会を提供している場合は、モデル構造や演算子について展開/最適化の同僚と話し合い、パフォーマンスの最適化に関する提案を得ることができます。

以下に、参考として一般的な結論をいくつか示します。

• Concat、Eltwise Sum、ReLU、LeakyReLU、ReflectionPad など、メモリアクセスが非常に集中的で、メモリアクセスパターンが連続している一部の演算子の場合、Tensor データの量が多いと、ソフトウェア実装の損失は非常に小さくなり、通常の状況では、測定されたメモリ帯域幅の上限に基本的に達することができます。フレームワークが融合戦略を採用すると、オーバーヘッドは基本的に 0 に達することができます。

• Conv/FC/Deconv などの演算子の場合、計算密度が非常に高いと、ほとんどのフレームワークはピーク計算能力に非常に近くなります。ただし、計算密度がそれほど高くない場合は、フレームワークによってパフォーマンスが異なるため、実際にテストして判断する必要があります。ただし、一般的な傾向としては、コンピューティング密度が高くなるほど、ハードウェアの使用率が高くなります。

• よく使用される演算子パラメータを使用するようにしてください。たとえば、Conv の場合は、3x3_s1/s2、1x1___s1/s2 などを使用するようにしてください。これらのよく使用されるパラメータは、特別に最適化されていることが多く、パフォーマンスが向上します。

4. まとめ

RoofLine モデルは、モデルが達成できるパフォーマンスの上限を推定するためにのみ使用できます。実際の展開では、ハードウェアの制限、システム環境、ソフトウェアの実装などの要因にも影響され、RoofLine モデルで定義されたパフォーマンスの上限を達成できない場合があります。

さらに、これらの要因はパフォーマンス曲線に強い非線形性をもたらすことが多いため、理論分析と実際の測定の間には一定のギャップが生じます。場合によっては、これらの要因がパフォーマンス曲線に重大な影響を及ぼし、オペレーターの特性に変化を引き起こすこともあります。したがって、このセクションで説明されているコンテンツは、いくつかの分析のアイデアとテクニックのみを提供します。

4。推論速度に関するモデル設計の推奨事項

上記で議論しましたが、最も実用的なことは、「より速い推論速度を達成するためにモデルを設計する方法」です。

私の個人的な提案をする前に、最初に、異なるハードウェア、異なる環境、異なるフレームワークの間に大きな違いがあるため、これらの提案はすべての条件下で適用できない場合があると述べなければなりません。アルゴリズムの設計またはパフォーマンステストについて質問がある場合は、展開/最適化の専門家に相談することをお勧めします。

さて、それ以上のアドがなければ（私はすでにたくさん言ってきました）、ここに私の個人的な提案のいくつかがあります：

方法論的提案：

• ネットワークの設計とオペレーターのパラメーターの選択を導くために、ターゲットハードウェアのピークコンピューティングパワーとメモリ帯域幅を理解して、できれば実際の測定値を使用します。

• テスト環境と実際の展開環境の違いを明確にします。

• さまざまなハードウェアプラットフォームの場合、異なるコンピューティング密度のネットワークを設計することができます。各プラットフォームのハードウェアコンピューティングパワーを完全に利用することができます（ただし、ワークロードは数回[顔をカバー]することができます。

• モデルサイズを表現/比較するために計算の量を使用することに加えて、モデルサイズを包括的に反映するために、特定のプラットフォームにメモリアクセスと実行時間を導入することをお勧めします。

• 実際の測定は、パフォーマンスを評価する最も正確な方法です。実際の測定と理論分析を組み合わせることにより、ネットワークを設計および反復することが推奨されます。

• パフォーマンスの問題に遭遇した場合、レイヤーごとにプロファイルをプロファイルし、展開/最適化の同僚との緊密な通信を維持して特定の問題を具体的に分析できます（コンピューティング関連理論を適切に理解している場合は、より効率的に通信できます）。

ネットワーク設計の提案：

• 低コンピューティングプラットフォーム（CPU、ローエンドGPUなど）の場合、モデルはハードウェアコンピューティングパワーによって簡単に制限されるため、低コンピューティングネットワークを使用して推論時間を短縮できます。

• ハイコンピューティングプラットフォーム（GPU、DSPなど）の場合、メモリアクセスの量をより多くの注意を払うために、コンピューティングの量を単純に削減することをお勧めします。計算量を単純に減らすと、ネットワークがハードウェアのメモリ集約型領域に該当する可能性があり、その結果、推論時間と計算量との間に非線形関係が発生する可能性があります。低いコンピューティング密度ネットワークと比較して、高いコンピューティング密度ネットワークは、ハードウェアの効率が高いため、処理時間が同じまたは短い場合があります。

• 推論パフォーマンスのためにネットワーク構造を設計するとき、ほとんどのフレームワークはこのタイプの構造でグラフの最適化を実行し、計算とメモリアクセスの量を効果的に削減できます。たとえば、conv-> bn-> reluは1つの演算子に融合されますが、conv-> relu-> bnはBNレイヤーを直接融合できません。

• たとえば、CONVには3x3_S1/S2、1x1 ___ S1/S2などを使用してください。

• CNNネットワークチャネルの数は、この数のチャネルで可能な限り4/8/16/32のパワーである必要があります（特定の数は、さまざまなプラットフォームとフレームワークで異なります）。

• コンピューティング時間に加えて、フレームワークは、ネットワークレイヤーの数に比例するネットワークトポロジ、メモリプール、スレッドプール、その他のオーバーヘッドも処理します。したがって、「大きくて浅い」ネットワークと比較して、「小さくて深い」ネットワークのオーバーヘッドはより高いです。一般的に言えば、支出のこの部分は大部分を占めていません。ただし、ネットワーク演算子が非常に断片化され、レイヤーの数が非常に大きい場合、このオーバーヘッドはマルチスレッドのスケーラビリティに影響を与え、無視できない時間のかかる要因にさえ影響します。

いくつかの追加の提案：

• ネットワーク構造と推論フレームワークのパフォーマンスを最適化することに加えて、他のエンジニアリング手法を使用してシステムの全体的なパフォーマンスを改善することも検討することもできます。たとえば、パイプライン推論サービスは、データの読み取りプロセスとコンピューティングプロセスに並行し、IOの遅延をマスクします。

この記事では、モデルサイズを評価するための4つの一般的なインジケーターを紹介します。これは、Rooflineモデルからの計算の複雑さ、パラメーターの数量、メモリアクセス、およびメモリの使用法について、モデルの推論速度に影響を与える要因を詳細に説明し、推論速度のモデル設計方法と提案を提供します。

この記事を書く目的は、アルゴリズムの学生に効果的なネットワーク設計の提案を提供するだけでなく、パフォーマンスの最適化に関する基本的な知識と分析のアイデアを伝え、アルゴリズムの設計と展開のギャップを削減し、推論に優しいネットワークモデルをより迅速かつ効率的に伝えることです。これが皆の仕事に役立つことを願っています。

私の知識は限られているため、エラーや省略がある場合は、コメントセクションにメッセージを残すことをお勧めします。

この記事のハイライトの概要

1.特定のハードウェア上のモデルの推論速度は、計算量だけでなく、アクセスボリューム、ハードウェア特性、ソフトウェア実装、システム環境などの他の多くの要因によっても影響を受け、複雑な特性を示します。したがって、ハードウェアを手元に置いてテストが便利な場合、実際のテストはパフォーマンスを評価する最も正確な方法です。

2。ピークコンピューティングパワーとメモリ帯域幅に加えて、ハードウェアの制限、システム環境、ソフトウェアの実装など、他の多くの要因がプログラムの実際のパフォーマンスに影響を与え、非線形特性をより深刻にします。したがって、ルーフラインモデルは、パフォーマンス評価の上限のみを提供することができ、達成できる実際のパフォーマンスを表すものではありません。実際のパフォーマンスを測定する最も正確な方法は、実際のデバイスをテストすることです。