このセクションでは、ML プロジェクトの開始時に以下を選択する方法について説明します。
- モデル アーキテクチャを
- オプティマイザー
- バッチサイズ
- 最初の構成で
前提条件
このセクションのアドバイスは、次のことを前提としています。
- すでに問題を定式化し、トレーニング データをある程度準備しています。
- トレーニングとテストのパイプラインはすでに設定済みです。
- デプロイした環境で測定する範囲を可能な限り代表する指標を選択して、実装済みです。
ここまでの前提条件がすべて満たされていれば、モデル アーキテクチャとトレーニング構成に時間を割くことができます。
モデル アーキテクチャを選択する
まず、次の定義から見ていきましょう。
- モデル アーキテクチャは、予測を生成するためのシステムです。モデル アーキテクチャには、入力データを予測に変換するためのフレームワークが含まれますが、パラメータ値は含まれません。たとえば、それぞれ 10 ノード、5 ノード、3 ノードの 3 つの隠れ層を持つニューラル ネットワークはモデル アーキテクチャです。
- モデルとは、モデル アーキテクチャに加えて、すべてのパラメータに特定の値を加えたものです。modelたとえば、モデルはモデル アーキテクチャの定義で説明されているニューラル ネットワークと、各ノードの重みとバイアスの特定の値で構成されます。
- モデル ファミリーは、一連のハイパーパラメータを使用してモデル アーキテクチャを構築するためのテンプレートです。
モデル アーキテクチャを選択するということは、実際には、さまざまなモデルのセット（モデルのハイパーパラメータの設定ごとに 1 つ）を選択することを意味します。
可能であれば、現在の問題にできるだけ近い問題に対処する、ドキュメント化されたコードベースを見つけるようにしてください。次に、出発点としてそのモデルを再現します。
オプティマイザーを選択する
あらゆるタイプの ML の問題とモデル アーキテクチャにおいて、「ベスト」なオプティマイザーは存在しません。オプティマイザーのパフォーマンスを比較するだけでも、困難です。🤖? 特に新しいプロジェクトを開始するときは、確立された一般的なオプティマイザーを使用することをおすすめします。
取り組んでいる問題のタイプに最も適したオプティマイザーを選択することをおすすめします。次のような確立されたオプティマイザーを使用することをおすすめします。
- 勢いのあるシンガポール ドル。Nesterov バリアントをおすすめします。
- Adam と NAdam。SGD よりも一般的で、勢いがあります。Adam には調整可能な引数が 4 つあります。すべて重要な引数です。Adam のハイパーパラメータの調整方法をご覧ください。
選択したオプティマイザーのすべての引数に注意してください。通常、ハイパーパラメータの数が多いオプティマイザーは、調整の労力を増やします。これは、プロジェクトの初期段階で、オプティマイザーの引数を問題として扱いながら他のさまざまなハイパーパラメータの最適な値（学習率など）を見つけようとするときに、特に問題になります。そのため、次の方法をおすすめします。
- プロジェクトの開始時に、調整可能なハイパーパラメータをあまり多くないオプティマイザーを選択します。次の 2 つの例を示します。
- 固定されたモメンタムで SGD。
- Adam と Epsilon、Beta1、Beta2 を固定。
- プロジェクトの後の段階では、デフォルト値を修正するのではなく、より多くのハイパーパラメータを調整する、より一般的なオプティマイザーに切り替えます。
バッチサイズの選択
要約: バッチサイズはトレーニングの速度を決定します。検証セットのパフォーマンスを直接調整するためにバッチサイズを使用しないでください。
バッチサイズは、トレーニング時間とコンピューティング リソースの消費量を大きく左右します。バッチサイズを増やすと、多くの場合、トレーニング時間が短縮されます。その結果、次のことが起こります。
- 一定の時間間隔内でハイパーパラメータをより詳細に調整できるため、より優れた最終的なモデルを生成できます。
- 開発サイクルのレイテンシが短縮され、新しいアイデアをより頻繁にテストできるようになります。
バッチサイズを増やすと、リソース使用量が減少または増加する可能性があります。また、リソース使用量は変更されません。
バッチサイズは、検証セットのパフォーマンスを調整するための調整可能なハイパーパラメータとして扱わないでください。以下のすべての条件が満たされている場合、モデルのパフォーマンスはバッチサイズに依存しません。
- すべてのオプティマイザーのハイパーパラメータは、適切に調整されています。
- 正則化は十分であり、適切に調整されています。
- トレーニング ステップの数が十分である。
どのバッチサイズを使用しても、同じ最終的なパフォーマンスを達成できるはずです（Shallue 他 2018 年と、検証セットのパフォーマンスを直接改善するためにバッチサイズをチューニングすべきではない理由をご覧ください）。
実現可能なバッチサイズを決定し、トレーニング スループットを見積もる
特定のモデルとオプティマイザーについて、使用可能なハードウェアは通常、さまざまなバッチサイズをサポートします。制限要因は通常、アクセラレータ メモリです。残念ながら、トレーニング プログラム全体を実行または少なくともコンパイルしなければ、どのバッチサイズがメモリに収まるかを計算するのは難しい場合があります。最も簡単な解決策は通常、異なるバッチサイズでトレーニング ジョブを実行することです（たとえば、2 のべき乗を増やすなど）。ジョブの 1 つが使用可能なメモリを超えるまで、少数のステップでトレーニング ジョブを実行することです。バッチサイズごとに、トレーニング スループットの信頼できる推定値が得られるように十分な期間トレーニングを行います。
トレーニングのスループット = 1 秒あたりに処理されるサンプルの数
または、同様にステップあたりの時間:
ステップあたりの時間 = バッチサイズ ÷ トレーニング スループット
アクセラレータがまだ飽和していないときに、バッチサイズが 2 倍になると、トレーニングのスループットも 2 倍（または 2 倍近く）になります。同様に、ステップあたりの時間は、バッチサイズが大きくなるまで一定（または少なくともほぼ一定）である必要があります。そうでない場合、トレーニング パイプラインには、I/O やコンピューティング ノード間の同期などのボトルネックがあります。続行する前に、ボトルネックを診断して修正することを検討してください。
トレーニングのスループットが最大バッチサイズまでしか増加しない場合は、ハードウェアがより大きなバッチサイズをサポートしていても、最大バッチサイズまでのバッチサイズのみを考慮します。バッチサイズを大きくするメリットは、トレーニングのスループットが向上することを前提とした内容です。解決しない場合は、ボトルネックを修正するか、小さいバッチサイズを使用します。
勾配累積は、ハードウェアがサポートできるよりも大きなバッチサイズをシミュレートするため、スループット上のメリットはありません。一般的に、適用された作業で勾配が蓄積されないようにする必要があります。
モデルやオプティマイザーを変更するたびに、この手順を繰り返さなければならない場合があります。たとえば、別のモデル アーキテクチャでは、より大きなバッチサイズがメモリに収まる場合があります。
バッチサイズを選択してトレーニング時間を最小限に抑える
トレーニング時間の定義は次のとおりです。
- トレーニング時間 = (ステップあたりの時間) x (合計ステップ数)
多くの場合、ステップあたりの時間は、実行可能なすべてのバッチサイズでほぼ一定であるとみなすことができます。これは以下の場合に該当します。
- 並列計算によるオーバーヘッドはありません。
- トレーニングのボトルネックはすべて診断され、修正されました。（トレーニングのボトルネックを特定する方法については、前のセクションをご覧ください。実際には、バッチサイズを増やすことによる少なくともある程度のオーバーヘッドが発生します。
バッチサイズが大きくなると、バッチサイズを変更するときに関連するすべてのハイパーパラメータを再調整すると、固定のパフォーマンス目標を達成するために必要なステップの合計数は通常減少します。（Shallue et al. 2018 を参照）。たとえば、バッチサイズを 2 倍にすると、必要なステップの総数が半分になる場合があります。この関係は完全スケーリングと呼ばれ、重要なバッチサイズまでのすべてのバッチサイズで維持する必要があります。
重要なバッチサイズを超えると、バッチサイズを大きくすると収率が減少します。つまり、バッチサイズを大きくしても、最終的にトレーニング ステップの数が減少することはありませんが、増加することはありません。したがって、トレーニング時間を最小化するバッチサイズは、通常、必要なトレーニング ステップ数を削減できる最大のバッチサイズです。このバッチサイズは、データセット、モデル、オプティマイザーに依存するため、新しい問題ごとに実験的に見つける以外に、その計算方法は未解決の問題です。🤖
バッチサイズを比較する場合は、次の違いに注意してください。
- サンプル予算またはエポック予算 - トレーニング サンプルのプレゼンテーションの数を修正しながら、すべてのテストを実行します。
- ステップ バジェット - 固定数のトレーニング ステップですべてのテストを実行する。
バッチサイズとエポック バジェットを比較しても、完璧なスケーリング レジームしか特定されません。バッチサイズを大きくしても、必要なトレーニング ステップの数を減らして、有意義なスピードアップを実現できる可能性があります。多くの場合、使用可能なハードウェアでサポートされている最大バッチサイズは、重要なバッチサイズよりも小さくなります。したがって、（テストを実行しない）経験則として、可能な限り最大のバッチサイズを使用することをおすすめします。最終的にトレーニング時間が増加する場合、バッチサイズを大きくしても意味がありません。
リソース消費を最小限に抑えるためのバッチサイズの選択
バッチサイズの拡大に関連するリソース費用には、次の 2 種類があります。
- 前払い料金。たとえば、新しいハードウェアを購入する場合や、トレーニング パイプラインを書き換えてマルチ GPU / マルチ TPU トレーニングを実装する場合などです。
- 使用料金。たとえば、チームのリソース予算に対する請求、クラウド プロバイダからの請求、電気やメンテナンスの費用などです。
バッチサイズの増加にかなりの先行費用がかかる場合は、プロジェクトが成熟し、費用とメリットのトレードオフを評価しやすくなるまで、バッチサイズの拡大を延期する方が適切な場合があります。マルチホストの並列トレーニング プログラムを実装すると、bugsや微妙な問題が発生する可能性があるため、とにかく単純なパイプラインから始めることをおすすめします。一方、多数の調整テストが必要になるプロセスの早い段階でトレーニング時間を大幅に短縮できると非常に有益な場合があります。
次のように計算して、総使用料金（複数の異なる種類の費用を含む場合があります）をリソース使用量と呼んでいます。
リソース消費 = ステップあたりのリソース消費量 x 総ステップ数
通常、バッチサイズを増やすと、ステップの合計数が減ります。リソースの消費量が増加するか減少するかは、ステップあたりの消費量の変化に応じて異なります。これはバッチサイズに応じて次のように異なります。
- バッチサイズを増やすと、リソースの消費量が減少する可能性があります。たとえば、バッチサイズの大きい各ステップを小さいバッチサイズと同じハードウェアで実行できる場合（ステップあたりの時間はわずかに増加します）、ステップあたりのリソース消費量の増加がステップ数の減少によって上回ることがあります。
- バッチサイズを増やしても、リソースの消費量は変わらない場合があります。たとえば、バッチサイズを 2 倍にすることで、必要なステップ数が半分になり、使用される GPU の数が 2 倍になっても、総消費量（GPU 時間単位）は変わりません。
- バッチサイズを増やすと、リソース消費量が増加する可能性があります。たとえば、バッチサイズを増やすためにハードウェアのアップグレードが必要な場合、ステップあたりの消費量の増加がステップ数の削減を上回る場合があります。
バッチサイズの変更にはほとんどのハイパーパラメータの再調整が必要
ほとんどのハイパーパラメータの最適値は、バッチサイズの影響を受けます。したがって、通常、バッチサイズを変更するには、チューニング プロセスを最初からやり直す必要があります。バッチサイズと最も強く相互作用するため、バッチサイズごとに個別に調整することが最も重要なハイパーパラメータは次のとおりです。
- オプティマイザーのハイパーパラメータ（学習率、運動量など）
- 正則化のハイパーパラメータ
プロジェクトの開始時にバッチサイズを選択する場合は、この点に注意してください。後で別のバッチサイズに切り替える必要がある場合、新しいバッチサイズに合わせて他のハイパーパラメータを再調整するのは、困難で時間とコストがかかる可能性があります。
バッチノルムとバッチサイズの関係
バッチノルムは複雑であり、一般的には、勾配計算とは異なるバッチサイズを使用して統計を計算します。詳細については、バッチ正規化の実装の詳細をご覧ください。
初期構成を選択する
ハイパーパラメータ調整の最初のステージとして、以下の項目の開始点を決定します。
- モデル構成（レイヤの数など）
- オプティマイザーのハイパーパラメータ（学習率など）
- トレーニング ステップ数
この初期構成を確認するには、手動で構成したトレーニングの実行と試行錯誤が必要です。
Google の指針は次のとおりです。
シンプルかつ比較的高速で、リソースの消費が比較的少なく、妥当なパフォーマンスが得られる構成を見つけます。
ここで
- シンプルとは、特殊な正規化やアーキテクチャのトリックなど、不要なパイプライン機能を回避することを意味します。たとえば、ドロップアウト正規化のないパイプライン（またはドロップアウト正則化が無効になっている）は、ドロップアウト正則化のあるパイプラインよりも単純です。
- 妥当なパフォーマンスは問題によって異なりますが、少なくとも、妥当なトレーニング済みモデルのほうが、検証セットにおいて偶然の確率よりもはるかに優れたパフォーマンスを発揮します。
高速でリソース消費を最小限に抑えた初期構成を選択すると、ハイパーパラメータ調整をより効率的に行えるようになります。たとえば、小規模なモデルから始めます。
トレーニングのステップ数を選択するには、次のようなバランスを考慮します。
- トレーニングのステップを増やすと、パフォーマンスが向上し、ハイパーパラメータ調整を簡素化できます。（詳細については、Shallue 他 2018 年をご覧ください）。
- 逆に、ステップが少ないほど、トレーニングの実行速度が速くなり、使用するリソースも少なくなります。サイクル間の時間が短縮され、より多くのテストを並行して実行できるため、調整の効率が向上します。さらに、プロジェクトの開始時に不必要に大きいステップ予算を選択すると、プロジェクトの後半で変更することが困難になる場合があります。たとえば、そのステップ数に合わせて学習率スケジュールを調整した場合などです。