ハードウェアとコードを分離し、APIを安定化したPyTorch Lightning 1.0.0が正式リリース

Keras と PyTorch はどちらも初心者にとても優しいディープラーニングフレームワークです。それぞれに利点があり、多くの研究者や開発者はフレームワークの選択に迷うかもしれません。この状況を踏まえて、grid.ai の CEO でありニューヨーク大学の博士である William Falcon 氏は、PyTorch に Keras コートを付与した PyTorch Lightning を作成しました。

[[347903]]

Lightning は PyTorch の非常に軽量なラッパーです。研究者は最もコアとなるトレーニングと検証のロジックを記述するだけで、残りのプロセスは自動的に完了します。したがって、これは Keras のような高レベルパッケージに少し似ており、ほとんどの詳細を隠し、最もわかりやすいインターフェースのみを保持しています。 Lightning は自動補完部分の正確性を確保できるため、コアトレーニングロジックの改良に非常に有利です。

本日、PyTorch Lightning は Twitter でバージョン 1.0.0 が利用可能になったことを発表し、PyTorch Lightning の動作原理と新しい API の詳細を説明した新しいブログ記事を公開しました。ウィリアム・ファルコン氏は、ユーザーがGitHubで複雑なプロジェクトを閲覧する際に、ディープラーニングのコードがそれほど難しくなくなる日を楽しみにしていると語った。

テスラAIの責任者であるアンドレイ・カルパシー氏も次のようにコメントしている。「これは素晴らしいし、将来性がある。PyTorch Lightningは、ディープラーニングコードの再構築を提唱し、「エンジニアリング（ハードウェア）」と「サイエンス（コード）」を分離し、前者をフレームワークに委ねる」

過去数か月間、PyTorch Lightning チームは API の微調整、ドキュメントの改善、チュートリアルの記録を行って、最終的に V1.0.0 を市場に投入しました。次のブログ投稿では、チームが PyTorch Lightning について詳しく説明しています。

ブログアドレス: https://medium.com/pytorch/pytorch-lightning-1-0-from-0-600k-80fc65e2fab0
GitHub アドレス: https://github.com/PyTorchLightning/pytorch-lightning

PyTorch Lightning の動作原理と目標

人工知能は、単一のフレームワークが進化するよりもはるかに速いペースで進化しています。ディープラーニングの分野は、複雑さと規模の両面で常に進化しています。 Lightning は、マルチ GPU およびマルチ TPU トレーニング、早期停止、ログ記録などの多くのエンジニアリングの詳細を抽象化しながら、複雑なモデル操作向けに設計されたユーザーエクスペリエンスを提供します。

PyTorch のようなフレームワークは、AI が主にネットワークアーキテクチャに重点を置いていた時代に登場しました。

これらのフレームは、非常に複雑なモデルを組み立てるためのすべての部品を提供し、研究と製造において優れた働きをします。ただし、GAN、BERT、オートエンコーダなどのモデルが相互作用し始めると、パラダイムは崩壊し、優れた柔軟性がすぐに失われ、プロジェクトの規模で維持することが困難になります。

以前のフレームワークとは異なり、PyTorch Lightning は、一連の相互作用モデル、つまりディープラーニングシステムをカプセル化するために使用されます。 Lightning は、多くのモデルが複雑なルールを使用して相互作用する、今日の世界のより複雑な研究および生産ユースケース向けに構築されています。

自動コーディングシステム

PyTorch Lightning の 2 番目の重要な原則は、ハードウェアと科学コードの分離です。 Lightning は、ユーザーに抽象化を提示することなく、大規模なコンピューティングを活用できるように進化しました。この分離により、コードを変更せずにラップトップの CPU を使用して 512 GPU をデバッグできるなど、以前は不可能だった新しい機能を実現できます。

最終的には、Lightning はコミュニティ主導のフレームワークになることを目指しています。

優れたディープラーニングモデルを構築するには、システムを適切に動作させるための多くの専門知識とコツが必要です。世界中で、何百人ものエンジニアや博士が同じコードを何度も繰り返し実装しています。現在、Lightning には、ディープラーニング分野で最も才能のある 300 人を超える貢献者のコミュニティがあり、同じエネルギーを割り当ててまったく同じ最適化を行うことを選択し、何千人もの人々が彼らの努力の恩恵を受けています。

[[347904]]

PyTorch Lightning 1.0.0 の新機能

Lightning 1.0.0 は安定した最終 API です。これは、コードが簡単に破られたり変更されたりすることができないため、Lightning を使用する研究者にとっては良いことです。

1. 研究と生産

Lightning の最大の利点は、最先端の AI 研究を大規模に実施できることです。これは、柔軟性を失うことなく、最大のコンピューティングリソース上で最も難しいアイデアを試すためにプロの研究者向けに設計されたフレームワークです。

Lightning 1.0.0 を使用すると、大規模なモデルを簡単にデプロイできます。コードは簡単にエクスポートできます。

つまり、大規模な機械学習エンジニアのチームを必要とせずに、データサイエンティストや研究者などのチームがモデルを作成できるようになります。

Lightning は、研究に必要な柔軟性を損なうことなく、研究者が生産時間を大幅に短縮できるように設計されています。

Grid AI は、クラウド上で大規模にモデルをトレーニングするためのネイティブプラットフォームです。このプラットフォームにより、ディープラーニングモデルを構築する研究者は、大規模な計算を反復し、ディープラーニングシステムの最大量のトラフィックを処理できるスケーラブルな環境にモデルを展開できるようになります。

2. メトリクス

pytorch_lightning.metrics は、PyTorch および PyTorch Lightning でのメトリックの開発と使用を容易にするために設計されたメトリック API です。更新された API には、統計を保存しながら、各ステップで複数の GPU (プロセス) にわたってメトリックを計算する組み込みメソッドが用意されています。これにより、ユーザーは分散バックエンドに関連する複雑さを気にすることなく、ステージの最後にメトリックを計算できます。

クラス LitModel(pl.LightningModule):
    __init__(self)を定義します。
        ...
 self.train_acc = pl .metrics.Accuracy()
 self.valid_acc = pl.metrics.Accuracy () です。 
 
    def training_step(自己、バッチ、batch_idx):
ロジット=自己(x)
        ...
        self.train_acc(ロジット, y) 関数
        # ログステップメトリック
        自己ログ('train_acc_step'、自己.train_acc) 
 
    def validation_step(self, batch, batch_idx):
ロジット=自己(x)
        ...
        自己.valid_acc(ロジット, y)
        # エポックメトリックをログに記録
        自己ログ('valid_acc', 自己.valid_acc)

カスタムメトリックを実装するには、Metric 基本クラスをサブクラス化し、__init__()、update()、compute() メソッドを実装するだけです。ユーザーが行う必要があるのは、add_state() を正しく呼び出して、DDP でカスタムインジケーターを実装することだけです。 add_state() を使用して追加されたメトリック状態変数に対して reset() を呼び出します。

 pytorch_lightning.metrics からメトリックをインポートします
 
クラス MyAccuracy(Metric): 
 
    __init__ を定義します(self、 dist_sync_on_step = False ):
        super().__init__( dist_sync_on_step dist_sync_on_step = dist_sync_on_step)
        self.add_state("correct"、デフォルト= torch.tensor (0)、 dist_reduce_fx = "sum" )
        self.add_state("total"、デフォルト= torch.tensor (0)、 dist_reduce_fx = "sum" ) 
         
    def update(self, preds: torch.Tensor, target: torch.Tensor):
        preds,ターゲット= self ._input_format(preds, ターゲット)
        preds.shape == target.shape であるとアサートする
        self.correct += torch.sum( preds == target)
        自己合計 += ターゲット数値() 
  
    def compute(self):
        self.correct.float() / self.total を返す

3. 手動最適化と自動最適化

Lightning を使用すると、ユーザーは grad をいつ有効/無効にするかを心配する必要はなく、training_step から添付されたグラフとともに損失を返すだけで、バックプロパゲーションを実行したり、オプティマイザーを更新したりでき、Lightning によって自動的に最適化されます。

 def training_step(自己、バッチ、batch_idx):
損失=自己.encoder(バッチ[0])
    リターンロス

ただし、GAN、強化学習、複数のオプティマイザーや内部ループを使用する一部の研究では、ユーザーは自動最適化をオフにして、トレーニングループを自分で完全に制御できます。

まず、自動最適化をオフにします。

トレーナー *=* トレーナー(自動最適化*=False*)

トレーニングループはユーザーの手に渡ります。

 def training_step(self, batch, batch_idx, opt_idx):
    (opt_a, opt_b, opt_c) = self.optimizers()
 loss_a =自己.ジェネレータ(バッチ[0])
    # loss.backwardの代わりにこれを使用すると半分を自動化できます
    # 精度など
    self.manual_backward(loss_a, opt_a, preserve_graph = True )を実行します。
    自己.manual_backward(loss_a, opt_a)
    opt_a.ステップ()
    opt_a.zero_grad()
 loss_b =自己.discriminator(バッチ[0])
    自己.manual_backward(loss_b, opt_b)
    ...

4. ログ記録

Lightning を使用すると、ロガーとの統合が非常に簡単になります。LightningModule の log() メソッドを呼び出すだけで、システムはログに記録された量をユーザーが選択したロガーに送信します。デフォルトでは Tensorboard が使用されますが、サポートされている他のロガーを選択することもできます。

 def training_step(自己、バッチ、batch_idx):
  自己ログ('my_metric', x)

Lightning は、.log() が呼び出される場所に基づいて、ログを記録するタイミング (各ステップおよび各エポック) を自動的に決定しますが、ユーザーは on_step と on_epoch を使用してデフォルトの動作を手動で上書きすることもできます。

ただし、on_epoch=True の場合、トレーニングフェーズ全体を通じてレコード値が蓄積されます。

 def training_step(自己、バッチ、batch_idx):
  self.log('my_loss', loss, on_step = True 、 on_epoch = True 、 prog_bar = True 、 logger = True )

5. データフロー

Lightning では、データフローを簡素化し、トレーニングループと検証ループでログをデータから分離するため、EvaResult と TrainResult が非推奨になりました。

各ループ (トレーニング、検証、テスト) には、次のように実装できる 3 つのフックがあります。

x_ステップ
x_ステップ終了
x_エポック_終了

データフローがどのように機能するかを示すために、次のコード実装ではトレーニングループ (つまり、x=training) を使用します。

アウト *=* []
 *for* バッチ *in* データ:
  出力 *=* トレーニングステップ(バッチ)
  outs*.*append(out)training_epoch_end(outs)

training_step で返されるものはすべて、training_epoch_end への入力として使用できます。

 def training_step(自己、バッチ、batch_idx):
予測= …
  {'loss': 損失、'preds': 予測} を返します
 
 def training_epoch_end(self, training_step_outputs):
  training_step_outputs の out の場合:
予測=出力['preds']
  # これらを使って何かする

検証およびテストループのコード実装でも同じ手順が実行されます。 DP または DDP2 分散モードを使用する場合 (つまり、GPU 上でバッチを分割する場合)、x_step_end を使用して手動で集計を実行します (またはこれを実装せず、lightning で自動集計を実行します)。

6. チェックポイント

Lightning は、ユーザーの最後のトレーニングエポックの状態とともに、現在の作業ディレクトリにチェックポイントを自動的に保存できるようになりました。これにより、トレーニングが中断された場合でも、ユーザーは再開できるようになります。

さらに、ユーザーはチェックポイントの動作をカスタマイズして、任意の数のトレーニングまたは検証ステップを監視することができます。たとえば、ユーザーが独自の検証損失に基づいてチェックポイントを更新する場合は、次のように実行できます。

検証損失など、監視するメトリックやその他の量を計算します。
log() メソッドを使用して、数量と val_loss などのキーを記録します。
ModelCheckpoint コールバック関数を初期化し、モニターを数量のキーに設定します。
コールバック関数 checkpoint_callback をトレーナーフラグに返します。

具体的なコードプロセスは次のとおりです。

 pytorch_lightning.callbacks から ModelCheckpoint をインポートします
 
クラス LitAutoEncoder(pl.LightningModule):
    def validation_step(self, batch, batch_idx):
        x, y =バッチ 
 y_hat =自己.backbone(x) 
 
        # 1. 損失を計算する
損失= F .cross_entropy(y_hat, y) 
 
        # 2. `val_loss` をログに記録する
        self.log('val_loss', 損失) 
 
 # 3. ModelCheckpoint コールバックを初期化し、'val_loss' を監視する
checkpoint_callback = ModelCheckpoint (モニター= 'val_loss' ) 
 
 # 4. コールバックを checkpoint_callback トレーナーフラグに渡す
トレーナー=トレーナー( checkpoint_callback checkpoint_callback = checkpoint_callback )