明らかに、ライオン、クマ、トラは友達です。

PyTorch-lightningは最近リリースされた、PyTorch用のKera風MLライブラリです。コアとなる学習と検証ロジックは開発者が担当し、残りの部分は自動化されます。（ちなみに、Kerasと言っても、定型的なコードや過度な単純化は一切ありません。）

Lightning のコア著者として、 Lightning 、 Fast.ai 、 PyTorch Igniteの主な違いについて何度も質問されてきました。

ここでは、これら3つのフレームワークを客観的に比較してみたいと思います。3つのフレームワークそれぞれのチュートリアルとドキュメントに記載されている客観的な類似点と相違点を列挙します。

モチベーション

うーん

Fast.aiはもともとfast.aiコースの指導を容易にするために開発されました（ https://www.fast.ai/2018/10/02/fastai-ai/ ）。最近では、GAN、強化学習、転移学習といった汎用的な手法を実装するためのライブラリとなっています。

PyTorch Ignite と PyTorch Lightning はどちらも、トレーニング ループと検証ループで何が起こるかの関数を定義することを研究者に要求することで、十分な柔軟性を提供するために作成されました。

Lightningには、さらに2つの野心的な目的があります。それは、反復性とベストプラクティスの民主化です。これらは、高度なPythorchユーザー（分散トレーニング、16ビット精度など）によってのみ実現可能です。これらの目的については、後のセクションで詳しく説明します。

したがって、基本的なレベルでは、対象ユーザーは明確です。fast.ai は「ディープラーニングに興味のある人」に焦点を当てており、他の 2 つは ML に興味がある、または ML を使用する「アクティブな研究者」 (生物学者、神経科学者など) です。

学習曲線

フレームオーバーロード

LightningとIgniteはどちらもインターフェースが非常にシンプルです。これは、ほとんどの作業が依然としてユーザーによって純粋なPythonで行われるためです。主な作業はそれぞれEngineオブジェクトとTrainerオブジェクト内で行われます。

ただし、Fast.ai は Pythorch をベースにした別のライブラリを学習する必要があります。この API はほとんどの場合、純粋な Pythorch コードを直接操作することはありません（一部は操作しますが）。ただし、DataBunches、DataBlocs などの抽象化が必要です。これらの API は、「最善の方法」が機能しない場合に非常に役立ちます。

しかし、研究者にとって重要なのは、別のライブラリを学習する必要がなく、他の抽象的な操作を必要とせずに、データ処理などの研究の重要な部分を直接制御できることです。

この場合、fast.ai ライブラリの学習曲線は急峻ですが、何かを行うための「最善」の方法を必ずしも知らず、ブラック ボックス アプローチを採用したいだけの場合は、それだけの価値があります。

ライトニング vs イグナイト

シェアするようなものです

上記からわかるように、ユースケースとユーザーが異なることを考慮すると、fast.ai をこれら 2 つのフレームワークと比較するのは不公平です (ただし、この記事の最後にある比較表に fast.ai を追加します)。

Lightning と Ignite の最初の大きな違いは、ユーザー インターフェイスです。

Lightning には、すべてのモデルが従う必要のある標準インターフェースがあり、9 つの必須メソッドで構成されています (LightningModule を参照: https://williamfalcon.github.io/pytorch-lightning/LightningModule/RequiredTrainerInterface/ )。

 class CoolModel (ptl.LightningModule) :
 def __init__ (self) :
 super(CoolModel, self).__init__()
 # not the best model...
 self.l1 = torch.nn.Linear( 28 * 28 , 10 )
 def forward (self, x) :
 return torch.relu(self.l1(x.view(x.size( 0 ), -1 )))
 def training_step (self, batch, batch_nb) :
 x, y = batch
 y_hat = self.forward(x)
 return { 'loss' : F.cross_entropy(y_hat, y)(y_hat, y)}
 def validation_step (self, batch, batch_nb) :
 x, y = batch
 y_hat = self.forward(x)
 return { 'val_loss' : F.cross_entropy(y_hat, y)(y_hat, y)}
 def validation_end (self, outputs) :
 avg_loss = torch.stack([x[ 'val_loss' ] for x in outputs]).mean()
 return { 'avg_val_loss' : avg_loss}
 def configure_optimizers (self) :
 return [torch.optim.Adam(self.parameters(), lr= 0.02 )]
 @ptl.data_loader
 def tng_dataloader (self) :
 return DataLoader(MNIST(os.getcwd(), train= True , download= True , transform=transforms.ToTensor()), batch_size= 32 )
 @ptl.data_loader
 def val_dataloader (self) :
 return DataLoader(MNIST(os.getcwd(), train= True , download= True , transform=transforms.ToTensor()), batch_size= 32 )
 @ptl.data_loader
 def test_dataloader (self) :
 return DataLoader(MNIST(os.getcwd(), train= True , download= True , transform=transforms.ToTensor()), batch_size= 32 )
 view rawfa_1.py hosted with ❤ by GitHub
 

この柔軟なフォーマットにより、学習と検証において最大限の自由度が得られます。このインターフェースは、単一のモデルではなく「システム」として捉えるべきです。システムは複数のモデル（GAN、seq-2-seqなど）で構成される場合もあれば、単純なMNISTの例のように単一のモデルで構成される場合もあります。

したがって、研究者は、これら 9 つの方法に焦点を当てるだけで、さまざまなクレイジーなことを好きなように試すことができます。

Ignite では非常によく似た設定が必要ですが、すべてのモデルが従う必要のある「標準」インターフェースはありません。

「実行」機能の定義は異なる場合があることに注意してください。つまり、トレーナーにさまざまなイベントが追加されたり、 「メイン、トレインなど」のように異なる名前が付けられたりする場合があります。

複雑なシステムでは、学習が奇妙な方法で進行することがあり（GANやRLを見るとわかりますが）、コードを見ただけでは何が起こっているのかよく分かりません。しかし、Lightningでは、学習ステップを見るだけで何が起こっているのか理解できます。

再現性

作品を再現しようとすると

前述したように、Lightning は「再現性」という、より野心的な別の動機で作成されました。

誰かの論文の実装を読んでも、何が起こっているのか理解するのは困難です。単に異なるニューラルネットワークアーキテクチャを設計するだけで済んだ時代は、もう過ぎ去りました。

現代の最先端 (SOTA) モデルは、実際には、特定の結果を達成するために多くのモデルやトレーニング手法を使用する「システム」です。

前述の通り、LightningModuleはモデルではなく「システム」です。そのため、高度なトリックや非常に複雑なトレーニングがどこで行われているのかを知りたい場合は、トレーニングと検証の手順を確認してください。

すべての研究プロジェクトと論文が LightningModule テンプレートを使用して実装されている場合、何が起こっているのかを知ることは「非常に」簡単になります (ただし、理解するのはおそらく簡単ではありません)。

AI コミュニティ全体でのこの標準化により、エコシステムの繁栄も可能になり、デプロイメントの自動化、システムバイアスの監査、さらにはブロックチェーンバックエンドへの重みのハッシュ化をサポートして監査が必要な重要な予測モデルを再構築するなど、LightningModule インターフェースを使用した優れた機能も実現できるようになります。

すぐに使える機能

IgniteとLightningのもう一つの重要な違いは、Lightningがすぐに使える（すぐに使える）機能をサポートしていることです。すぐに使えるとは、追加のコードを一切必要としないことを意味します。

これを説明するために、同じマシンの複数の GPU でモデルをトレーニングしてみましょう。

「イグナイト（」 「デモ」 ）」

「ライトニング（」 「デモ」 ）」

どちらも悪くありませんが、複数のマシンで複数の GPU を使いたい場合はどうすればよいでしょうか。200 個の GPU でトレーニングしてみましょう。

"発火"

…

わかりました。組み込みのサポートはありません…この例 ( https://github.com/pytorch/ignite/blob/master/examples/mnist/mnist_dist.py ) を拡張して、スクリプトを簡単にコミットできる方法を追加する必要があります。そして、重みやログを全プロセスで上書きするのではなく、読み込み/保存時に注意する必要があります…お分かりですね。

稲妻

Lightningを使えば、ノード数を設定して適切なジョブを送信するだけです。ジョブの適切な設定方法については、こちらの詳細なチュートリアルをご覧ください： https://medium.com/@_willfalcon/trivial-multi-node-training-with-pytorch-lightning-ff75dfb809bd

すぐに使える機能とは、「何もしなくても使える」機能のことです。つまり、現時点ではほとんどの機能が必要ないかもしれませんが、例えばグラデーションの蓄積、グラデーションクリッピング、16ビットトレーニングなどが必要になったときに、チュートリアルを読んで何日も何週間もかけて使いこなす必要はありません。

適切な Lightning フラグを設定し、研究を続行するだけです。

Lightningにはこれらの機能がプリロードされており、ユーザーはエンジニアリング設計ではなく研究に多くの時間を費やすことができます。これは、物理学者や生物学者など、プログラミングにそれほど精通していない非コンピュータサイエンス/データサイエンス分野の研究者にとって特に便利です。

これらの機能により、PyTorch の機能が民主化され、上級ユーザーのみが実装に時間を費やすことになります。

以下は、機能別にグループ化された 3 つのフレームワークの機能の比較表です。

何か重要なことを見落としている場合は、コメントを残していただければフォームを更新します。

高性能コンピューティング

デバッグツール

可用性

結論

ここでは、これら3つのフレームワークを多層的に、かつ詳細に比較します。それぞれに独自の利点があります。

最新のベスト プラクティスを学習中またはよく知らない場合、高度なトレーニング手法は必要なく、新しいライブラリを学習する時間が十分にある場合は、fast.ai を使用してください。

より柔軟性が必要な場合は、Ignite または Lightning を選択できます。

非常に高度な機能は必要なく、TensorBoard、勾配累積、分散トレーニングなどのサポートを追加できる場合は、Ignite を使用してください。

より高度な機能、分散トレーニング、最新かつ最高のディープラーニングトレーニング手法が必要であり、世界規模での標準化を実現したい場合は、Lightning を使用してください。

オリジナルリンク: https://towardsdatascience.com/pytorch-lightning-vs-pytorch-ignite-vs-fast-ai-61dc7480ad8a