新しいプロジェクトを開始するためのガイド

このセクションでは、キャンペーンの開始時に次の要素を選択する方法について説明します。 ML プロジェクトです

  • アーキテクチャを
  • オプティマイザー
  • バッチサイズ
  • 初期構成を
で確認できます。

前提条件

このセクションのアドバイスは、次のことを前提としています。

  • すでに問題が定式されていて、 トレーニングデータをある程度 用意しました
  • トレーニングとテスト用のパイプラインはすでに設定されています。
  • 代表的な指標をすでに選択し、実装している 測定するものを可能な限り正確に予測します

前述の前提条件をすべて満たしていれば、次の手順を実施できます。 モデルのアーキテクチャとトレーニング構成に 時間を費やすことができます

モデル アーキテクチャを選択する

まず、次の定義を確認しましょう。

  • モデル アーキテクチャは、予測を生成するシステムです。 モデル アーキテクチャには入力データを変換するためのフレームワークが含まれる モデルにフィードしますが、モデルに パラメータ値を使用します。たとえば 10 ノード、5 ノード、3 ノードの 3 つの隠れ層からなるニューラル ネットワークです。 モデルアーキテクチャです
  • モデルとは、モデル アーキテクチャに、すべてのモデルに特定の値を あります。たとえば、モデルはニューラル ネットワークが モデルアーキテクチャの定義に指定されています。また、 重みとバイアスを表します
  • モデル ファミリーは、モデル アーキテクチャを構築するためのテンプレート 一連のハイパーパラメータが与えられます。

モデル アーキテクチャを選択するということは、実際には一連の異なるアーキテクチャを （モデルのハイパーパラメータの設定ごとに 1 つ）あります。

可能であれば、何かに対処できるドキュメント化されたコードベースを探す できるだけ近くなるように次に、そのモデルを 出発点になります。

オプティマイザーの選択

どのオプティマイザーも「最良」ではないあらゆるタイプの ML 問題に適用できる 学習しますオプティマイザーのパフォーマンスを比較するだけでも 困難です。🤖? 確立された一般的なオプティマイザーを使用することをおすすめします。 特に新しいプロジェクトの開始時に重要です

問題のタイプに対して、最も一般的なオプティマイザーを選択することをおすすめします 確認しましょう。確立された次のオプティマイザーをおすすめします。

選択したオプティマイザーのすべての引数に注意します。 一般的に、オプティマイザーのハイパーパラメータが多いほど、調整の労力も多くなります。 プロジェクトの初期段階では特に 他のさまざまなハイパーパラメータの最適値を見つけようとしています。 オプティマイザーの引数を 便利です。したがって、次の方法をおすすめします。

  1. プロジェクトの開始時に、多くのチューニング可能な設定のないオプティマイザーを選択する ハイパーパラメータです。以下に 2 つの例を示します。 <ph type="x-smartling-placeholder">
      </ph>
    • SGD は勢いが固定されています。
    • 固定の Epsilon、Beta1、Beta2 を備えた Adam。
  2. プロジェクトの後半の段階で、より一般的なオプティマイザーに切り替えます。 ハイパーパラメータをデフォルト値に固定する代わりに調整できます。

バッチサイズを選択する

まとめ: バッチサイズはトレーニング速度を左右します。バッチサイズを使用しない 検証セットのパフォーマンスを直接調整できます。

バッチサイズによってトレーニング時間とコンピューティング リソースが大きく決まる できます。バッチサイズを大きくするとトレーニング時間が短くなり 意味:

  • 一定の時間内でハイパーパラメータをより細かく調整できる より優れた最終モデルにつながる可能性があります。
  • 開発サイクルのレイテンシを短縮し、新しいアイデアを可能に 頻繁にテストを行います。

バッチサイズを大きくすると、リソースの消費量が増減する可能性があります。 リソース消費量を変更せずに済みます

バッチサイズを検証用の調整可能なハイパーパラメータとして扱わない set パフォーマンスに基づいて生成されます。すべてのエンドポイントの 次の条件を満たす場合は、モデルのパフォーマンスが バッチサイズ:

  • すべてのオプティマイザーのハイパーパラメータが適切に調整されている。
  • 正則化で十分、十分に調整されています。
  • トレーニングのステップ数が十分である。

どのバッチサイズでも、同じ最終パフォーマンスを達成できる必要があります。 （Shallue et al. 2018、 バッチサイズを調整して直接改善すべきではない理由 検証セットのパフォーマンスは？）

実行可能なバッチサイズを決定し、トレーニングのスループットを見積もる

特定のモデルとオプティマイザーに対して、使用可能なハードウェアでは通常、 バッチサイズを選択できます通常、制約要因は 使用されます。残念ながら、どの Pod が バッチサイズがメモリに収まりますが、実行時に 完全なトレーニングプログラムです最も簡単なソリューションは通常、トレーニング ジョブを実行することです。 異なるバッチサイズで（たとえば、2 の累乗を増やすなど）、 いずれかのジョブが使用可能なメモリを超過するまでのステップ数を繰り返す必要があります。対象 信頼性の高い推定値を得るのに十分な時間トレーニングを トレーニングのスループット:

トレーニングのスループット = 1 秒あたりに処理されるサンプルの数

1 歩あたりの時間:

ステップあたりの時間 = バッチサイズ ÷ トレーニング スループット

アクセラレータがまだ飽和していないときに、バッチサイズが 2 倍になると、 トレーニングのスループットも 2 倍（または少なくともほぼ 2 倍）になります。 同様に、ステップあたりの時間は一定（少なくともほぼ バッチサイズが大きくなります。そうでない場合は トレーニング パイプラインに I/O や同期などのボトルネックがある コンピューティング ノード間のボトルネックの診断と修正を検討する 確認してから続行してください。

トレーニングのスループットが、ある最大バッチサイズまでしか増加しない場合、 最大バッチサイズに達するまでのバッチサイズのみ 検討してください サポートされるバッチサイズが大きくなります。 バッチサイズを大きくするメリットはすべて、トレーニングのスループットが 増加します。解決しない場合は、ボトルネックを修正するか、小さいバッチサイズを使用します。

勾配累積は、ハードウェアが処理できるバッチサイズよりも大きなバッチサイズをシミュレーションする スループット上のメリットはありません。すべきこと 一般的には、応用作業での勾配蓄積を避ける必要があります。

モデルを変更したり、変更したりするたびに、この手順を繰り返す オプティマイザーですたとえば、モデル アーキテクチャが異なると、 メモリに収まるようにバッチサイズを大きくします

バッチサイズを選択してトレーニング時間を最小化する

Google におけるトレーニング時間の定義は次のとおりです。

  • トレーニング時間 =（ステップあたりの時間）x（合計ステップ数）

多くの場合、1 ステップあたりの時間はほぼ一定とみなすことができます。 すべてのバッチサイズで定義しています。これは次の場合に該当します。

  • 並列計算によるオーバーヘッドはありません。
  • トレーニングのボトルネックはすべて診断され、修正済みです。 （ID プロバイダを識別する方法については、前のセクションをご覧ください）。 特定できます実際には、少なくとも一部の Pod は オーバーヘッドが増加します。

バッチサイズが大きくなると、必要なステップの総数は 固定されたパフォーマンス目標は通常、すべての ハイパーパラメータを指定するようにしてください。（参照: Shallue 他、2018 年）。） たとえば、バッチサイズを 2 倍にすると、バッチサイズの合計が 手順が必要です。この関係は完全なスケーリングと呼ばれ、 重要なバッチサイズまで、すべてのバッチサイズで保持します。

重要なバッチサイズを超えたところでバッチサイズを大きくすると、 収益の減少につながりますつまり、最終的にバッチサイズを増やすと、 トレーニングのステップ数は減りませんが、増加することはありません。 そのため、トレーニング時間を最小限に抑えるバッチサイズは通常、 トレーニングのステップ数を削減できる最大のバッチサイズ 必要ありません。このバッチサイズは、データセット、モデル、 その計算方法は未解決の問題であり、 新しい問題ごとにテストしています。🤖

バッチサイズを比較する際は、次の違いに注意してください。

  • 予算の例またはエポック予算 - すべてのテストを実施しながら トレーニングサンプルの プレゼンテーションの数を固定します
  • ステップ予算 - 一定数ですべてのテストを実行する 示しています

バッチサイズとエポック予算を比較しても、完璧な スケーリング レジームがあります。たとえバッチサイズが大きくなるほど、 必要なトレーニング ステップの数を削減することで、大幅な高速化を達成しました。 多くの場合、利用可能なハードウェアでサポートされる最大バッチサイズ 重要なバッチサイズよりも小さくなりますそのため、適切な 経験上（テストを実行せずに）最も大きなバッチサイズを 終了しても、バッチサイズを大きくしても意味はありません。 トレーニング時間が長くなります

バッチサイズを選択してリソースの消費を最小限に抑える

バッチサイズの増加に関連するリソースコストには、次の 2 種類があります。

  • 前払い費用。たとえば、新しいハードウェアの購入や トレーニング パイプラインを使用して、マルチ GPU / マルチ TPU トレーニングを実装します。
  • 使用料金。たとえば、チームのリソース予算に対する課金、 クラウド プロバイダからの請求、電気 / メンテナンス費用。

バッチサイズを増やすために多大な先行コストがかかる場合は、 プロジェクトが生成されるまでバッチサイズの増加を 費用対効果のトレードオフを評価しやすくなっています。 マルチホストの並列トレーニング プログラムを実装すると、 バグと 微妙な問題 そのため、最初はシンプルな構成から 見てみましょう一方、トレーニング時間の大幅な短縮は、 多数のチューニングを行う場合に、プロセスの早い段階で 必要があります。

Google では使用料金の総称で、これには複数の異なる の種類の費用など）をリソース使用量として計算します。

リソース消費量 = ステップあたりのリソース消費量 x 総ステップ数

バッチサイズを増やすと、通常はステップの総数が少なくなります。 リソース消費量が増減するかどうかは、 ステップあたりの消費量がどのように変化するかは、次のようにバッチサイズによって異なります。

  • バッチサイズを増やすと、リソースの消費量が減少する可能性があります。 たとえば、バッチサイズの大きい各ステップを より小さなバッチサイズと同じハードウェアで動作させることが 増加するなど）、リソースの増加によって 消費電力のステップあたりの消費電力は、 必要ありません。
  • バッチサイズを増やしても、リソース消費量が変化しない場合があります。 たとえば、バッチサイズを 2 倍にすることでステップ数が半減する場合 使用される GPU の数が 2 倍になり、 （GPU 時間単位）は変わりません。
  • バッチサイズを増やすと、リソースの消費量が増加する可能性があります。 たとえば、バッチサイズを増やすためにハードウェアをアップグレードする必要が ステップあたりの消費量の増加が ステップ数です

バッチサイズを変更すると、ほとんどのハイパーパラメータを再チューニングする必要がある

ほとんどのハイパーパラメータの最適値はバッチサイズの影響を受けます。 したがって、バッチサイズを変更するには、通常、チューニングを開始する必要があります。 同じプロセスを繰り返します最も強く相互作用するハイパーパラメータ 異なるため、個別にチューニングすることが非常に重要です。 は、次のとおりです。

  • オプティマイザーのハイパーパラメータ（学習率、モメンタムなど）
  • 正則化ハイパーパラメータ

プロジェクトの開始時にバッチサイズを選択する場合は、この点に注意してください。 後で別のバッチサイズに切り替える必要がある場合は、 他のハイパーパラメータのチューニングが難しく、時間も費用もかかる 新しいバッチサイズを指定します

バッチノルムとバッチサイズの関係

バッチのノルムは複雑であるため、一般に、別のバッチを使用する必要があります。 勾配計算よりもサイズが大きくなります。詳しくは、 バッチ正規化の実装 details をご覧ください。

初期設定を選択する

ハイパーパラメータ調整の第一歩は 開始点として以下を確認してください。

  • モデル構成（レイヤの数など）
  • オプティマイザーのハイパーパラメータ（学習率など）
  • トレーニングステップの数

この初期構成を決定するには、手動で構成する必要があります。 試行錯誤の繰り返しです

Google の指針は次のとおりです。

シンプルで、比較的高速、比較的リソース消費量の少ないものを見つける 妥当なパフォーマンスを実現する構成。

ここで

  • シンプルとは、特別な アーキテクチャのコツに関するものです。たとえば、Cloud Storage バケットのない ドロップアウト 正則化 （またはドロップアウト正則化が無効になっている場合）は、 ドロップアウト正則化です
  • 妥当なパフォーマンスは問題にもよりますが、少なくとも 妥当なトレーニング済みモデルが偶然よりもはるかに優れたパフォーマンスを発揮する 必要があります。

最小限の消費電力で迅速に初期構成を選択できる ハイパーパラメータ調整がはるかに効率的になります。 たとえば、小さいモデルから始めます。

トレーニング ステップの数を選択するには、次の緊張のバランスを取ります。

  • トレーニングのステップ数を増やすと、パフォーマンスが向上し、ハイパーパラメータが簡素化される します。（詳しくは、 Shallue 他、2018）。
  • 逆に、トレーニングのステップ数が少ないと、各トレーニングの実行は 高速化し、使用するリソースも少なくて済み、 サイクル間隔が短縮され、より多くのテストを並行して実行できます。 また、キャンペーンの開始時に不必要に大きいステップ予算を選択したとしても、 後から変更するのは困難かもしれません。たとえば そのステップ数の学習率のスケジュールを調整したら、
前へ
はじめに
次へ
モデルのパフォーマンスを改善するための科学的アプローチ