PyTorch Lightning 1.1: notebooks : Lightning フラグへのイントロダクション (2) (翻訳/解説)
翻訳 : (株)クラスキャット セールスインフォメーション
作成日時 : 02/22/2021 (1.1.x)

* 本ページは、PyTorch Lightning ドキュメントの以下のページの後半を翻訳した上で適宜、補足説明したものです：

• notebooks : Introduction to Lightning Flags

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

 

 

notebooks : Lightning フラグへのイントロダクション (2)

デバッグ・フラグ

Lightning は貴方のモデルをデバッグすることを容易にするための幾つかのフラグを提供します :

 

Fast Dev Run

デバッグする時間を節約する助けをするために、最初の実行は fast_dev_run フラグを使用するべきです。

これはログを生成したりチェックポイントをセーブしたりはしませんが、それが意図したように動作することを確実にするために貴方のコードの総ての行にタッチします。

このフラグについてコンパイラのように考えてください。コードに変更を加えて、変更がバグフリーであることを確かめるためにこのフラグで Trainer を実行します。

trainer = pl.Trainer(fast_dev_run=True)

trainer.fit(model, train_loader, val_loader)

 

overfit_batches

Uses this much data of the training set. 非ゼロである場合、検証とテストのために同じ訓練セットを使用します。訓練 detaloader が shuffle=True を持つ場合、Lightning は自動的にそれを無効にします。

素早くデバッグしてり意図的に overfit させようとするために有用です。

# use only 1% of the train set (and use the train set for val and test)
trainer = pl.Trainer(overfit_batches=0.01)

trainer.fit(model, train_loader, val_loader)

# overfit on 10 of the same batches
trainer = pl.Trainer(overfit_batches=10)

trainer.fit(model, train_loader, val_loader)

あるいは実行するためのデータのパーセンテージを表すための float

# run through only 25% of the test set each epoch
trainer = pl.Trainer(limit_test_batches=0.25)

trainer.fit(model, train_loader, val_loader)

複数のテスト dataloader の場合、limit は各 dataloader に個別に適用されます。

 

accumulate_grad_batches

バッチサイズは勾配の推定の精度を制御します。小さいバッチサイズは少ないメモリを使用しますが、精度を減少させます。NLP transformer のような、大規模なモデルを訓練するとき、backwards() を呼び出す前に勾配を累積することは有用です。それは単一ステップで GPU/TPU 上に実際に収められるより大きなバッチサイズを可能にします。

k バッチ毎に (あるいは辞書へのセットアップとして) 勾配を蓄積するためにaccumulate_grad_batches を使用します。Trainer はまた最後の不可分な (= indivisible) ステップ数のために optimizer.step() を呼び出します。

例えば、4 バッチ毎に蓄積するために accumulate_grad_batches を 4 に設定します。この場合には実際のバッチサイズは batch_size*4 ですので、バッチサイズが 32 であれば、それは 事実上 128 になります。

# accumulate every 4 batches (effective batch size is batch*4)
trainer = pl.Trainer(accumulate_grad_batches=4)

trainer.fit(model, train_loader, val_loader)

エポック毎に異なる累積を指定するために辞書を渡すこともできます。エポック 1 から 4 のためには累積なし、エポック 5 から 10 のためには 3 バッチ、そしてその後は 20 バッチ累積するためにそれを {5: 3, 10: 20} と設定できます。

# no accumulation for epochs 1-4. accumulate 3 for epochs 5-10. accumulate 20 after that
trainer = pl.Trainer(accumulate_grad_batches={5: 3, 10: 20})

trainer.fit(model, train_loader, val_loader)

 

16 bit 精度

PyTorch のような殆どの深層学習フレームワークは 32-bit 浮動小数点計算で訓練します。

しかし多くのモデルは依然として精度の半分を使用して完全な精度を達成できます。

2017 年に、NVIDIA 研究者は 32 と 16 bit 精度の組合せ (混合精度としても知られています) を利用して 32 bit 精度訓練と同じ精度を獲得しました。

主要な 2 つの優位点は :

• メモリ要求の削減、これはより大きなバッチサイズとモデルを可能にします。
• そして計算のスピードアップ。ampere, turing と volta アーキテクチャで 16 bit 精度モデルは少なくとも 3 倍高速で訓練できます。

PyTorch 1.6 の時点で、NVIDIA and Facebook は混合精度機能を AMP パッケージ, torch.cuda.amp として PyTorch コアに移しました。

このパッケージは NVIDIA により開発された apex パッケージに取って代わります。

 

precision

完全精度 (32) と半精度 (16) の間を切り替えるために precision フラグを使用します。CPU, GPU or TPU 上で利用可能です。

PyTorch 1.6+ を使用するとき Lightning は 16-bit をサポートするために native amp 実装を利用します。

TPU 上で使用される場合 torch.bfloat16 を使用しますが tensor 表示は依然として torch.float32 を示します。

# 16-bit precision
trainer = pl.Trainer(gpus=1, precision=16)

trainer.fit(model, train_loader, val_loader)

Lightning の早いバージョンでは、16-bit 精度のために NVIDIA Apex を使用しています。Apex は 16-bit を試みるための最初のライブラリでそれから自動混合精度ライブラリ (amp, automatic mixed precision) が 1.6 の時点でコア PyTorch にマージされました。

貴方が Apex の使用を要求する場合、amp_backend フラグを ‘apex’ に設定して Apex を貴方自身でインストールすることができます。

trainer = pl.Trainer(gpus=1, precision=16, amp_backend='apex')

trainer.fit(model, train_loader, val_loader)

 

amp_level

Apex は 4 つの最適化レベルを含みます : O0 (FP32 訓練) O1 (Conservative 混合精度): 幾つかのホワイトリスト ops だけが FP16 で成されます。O2 (Fast 混合精度): これは標準的な混合精度訓練です。それは FP32 マスター重みを維持し optimizer.step は FP32 マスター重み上で直接的に作用します。O3 (FP16 訓練): full FP16. Passing keep_batchnorm_fp32=True can speed things up as cudnn batchnorm is faster anyway.

# default used by the Trainer
trainer = pl.Trainer(gpus=1, precision=16, amp_backend='apex', amp_level='O2')

trainer.fit(model, train_loader, val_loader)

 

auto_scale_batch_size

Lightning は auto_scale_batch_size フラグを使用してモデルを改良する手助けができます、これは訓練を始める前にメモリに収まる最大のバッチサイズを見つけようとします。より大きなバッチサイズはしばしば勾配のより良い推定を yield しますが、より長い訓練時間という結果になるかもしれません。

メモリに収まる最大のバッチサイズを見つけようとするバッチサイズ finder を最初に実行するためにそれは True に設定します。結果は LightningModule の self.batch_size にストアされます。

trainer = pl.Trainer(auto_scale_batch_size=True)

trainer.tune(model, train_dataloader=train_loader, val_dataloaders=val_loader)

値を power に設定することができます。 power スケーリングは 1 のバッチサイズから始めて out-of-memory (OOM) エラーに遭遇するまでバッチサイズを倍増し続けます。

trainer = pl.Trainer(auto_scale_batch_size='power')

trainer.tune(model, train_dataloader=train_loader, val_dataloaders=val_loader)

それを binsearch に設定することもできます、これは二分探索を遂行することによりバッチサイズを調整し続けます。

# run batch size scaling, result overrides hparams.batch_size
trainer = pl.Trainer(auto_scale_batch_size='binsearch')

trainer.tune(model, train_dataloader=train_loader, val_dataloaders=val_loader)

この特徴はモデルの hparams の batch_size フィールド, i.e. model.hparams.batch_size が存在してこのアルゴリズムの結果で override されることを想定しています。

更に、この特徴が動作するためには train_dataloader() がこのフィールドに依拠するべきです。

アルゴリズムは短く言えば以下により動作します :

1. モデルと trainer の現在の状態をダンプする。
2. 反復的に収束か最大試行数 max_trials (default 25) 最大数に達するまで :
   • trainer の fit() メソッドを呼び出します。これは訓練ステップの steps_per_trial (default 3) 数を評価します。ステップの間に割当てられる tensor (訓練バッチ, 重み, 勾配 etc.) が非常に大きいメモリ消費量を持つ場合、各訓練ステップは OOM エラーを引き起こす可能性があります。
     • OOM エラーに遭遇した場合、バッチサイズを減らします
     • そうでないならそれを増やします。
   • バッチサイズがどれだけ増加/減少されるかは選択されたストラテジーにより決定されます。
3. 見つけられたバッチサイズは model.hparams.batch_size にセーブされます。
4. モデルと trainer の初期状態をリストアします。

 

auto_lr_find

深層学習訓練のための良い学習率の選択は良いパフォーマンスと高速な収束のために不可欠です。

学習率を自己調整する Adam のような optimizer でさえより最適な選択から恩恵を受けることができます。

良い初期学習率を選択することに関する当て推量の総量を減じるために、Lightning 自動学習率 finder を利用できます。

各処理バッチと対応する損失がログ記録された後、学習率 finder は学習率が増やされるところで小さいな実行を行ないます。この結果は lr vs. loss プロットでこれは最適な初期 lr の選択のためのガイダンスとして利用できます。

warning: 当面は、この特徴は単一 optimizer を持つモデルでのみ動作します。DDP のための LR サポートはまだ実装されていませんが、それはすぐにやってきます。

auto_lr_find=

殆どの基本的なユースケースで、Trainer(auto_lr_find=True) による trainer 構築の間にこの特徴は有効にできます。.fit(model) が呼び出されるとき、LR finder はどのような訓練が成される前にも自動的に実行されます。見つけられて使用される lr はモデルの総ての他のハイパーパラメータと一緒にコンソールに書かれてログ記録されます。

# default used by the Trainer (no learning rate finder)
trainer = pl.Trainer(mnist_model, auto_lr_find=False)

このフラグは貴方の学習率を設定し、これは self.lr or self.learning_rate を通してアクセスできます。

class LitModel(LightningModule):

    def __init__(self, learning_rate):
        self.learning_rate = learning_rate

    def configure_optimizers(self):
        return Adam(self.parameters(), lr=(self.lr or self.learning_rate))

# finds learning rate automatically
# sets hparams.lr or hparams.learning_rate to that learning rate
trainer = pl.Trainer(mnist_model, auto_lr_find=True)

trainer.tune(model, train_dataloader=train_loader, val_dataloaders=val_loader)

任意の値を使用するにはそれを auto_lr_find に設定します。

trainer = pl.Trainer(mnist_model, auto_lr_find='my_value')

trainer.tune(model, train_dataloader=train_loader, val_dataloaders=val_loader)

内部的には、tune を呼び出すときそれは学習率 finder を実行しています。

任意の実際の訓練を行なう前に学習率 finder の結果を調べたり、あるいは単にアルゴリズムのパラメータで遊ぶことを望む場合、これは trainer の lr_find メソッドを起動することにより成されます。この典型的なサンプルは次のようなものです :

trainer = pl.Trainer(auto_lr_find=True)

# Run learning rate finder
lr_finder = trainer.lr_find(model)

# Results can be found in
lr_finder.results

# Plot with
fig = lr_finder.plot(suggest=True)
fig.show()

# Pick point based on plot, or get suggestion
new_lr = lr_finder.suggestion()

# update hparams of the model
model.hparams.lr = new_lr

# Fit model
trainer.fit(model)

lr_finder.plot() により生成された図は下の図のようなものに見えるはずです。最低の損失を得る学習率ではなく、代わりに最も急な下り坂の真ん中のどれか (赤点) を選択することを勧めます。これが py lr_finder.suggestion() により返されるポイントです。

 

ベンチマーク

benchmark=True を設定することにより貴方のシステムをスピードアップしようとすることができます、これは cudnn.benchmark を有効にします。このフラグは入力サイズが変わらない場合にシステムのスピードを増加する傾向にあります。このフラグは与えられたハードウェア構成に対して cudnn auto-tuner にアルゴリズムの最適なセットを探させます。これは通常はより高速なランタイムに繋がります。しかし入力サイズが各反復で変化する場合には、cudnn は新しいサイズが現れるたびにベンチマークを行ないますので、多分より悪いランタイム性能に繋がるでしょう。

trainer = pl.Trainer(gpus=1, benchmark=True)

trainer.fit(model, train_loader, val_loader)

 

deterministic

PyTorch は再現可能な結果を保証しません、同一のシードを使用しているときでさえも。再現可能な結果を保証するため、deterministic フラグを True に設定することにより貴方のプロセスから殆どのランダムネスを除去できます。

それはシステムを遅くするかもしれないことに注意してください。

trainer = pl.Trainer(gpus=1, deterministic=True)

trainer.fit(model, train_loader, val_loader)

 

勾配爆発と消失

track_grad_norm

track_grad_norm フラグを使用して勾配を爆発させたり消失させることを識別するために grad norm をデバッグできます。

2-norm を追跡するために 2 を設定できます。あるいは p-norm のために p です。

# track the 2-norm
trainer = pl.Trainer(track_grad_norm=2)

trainer.fit(model, train_loader, val_loader)

infinity-norm のために ‘inf’ が設定されるかもしれません。

trainer = pl.Trainer(track_grad_norm='inf')

trainer.fit(model, train_loader, val_loader)

 

勾配クリッピング

勾配の爆発は勾配が訓練で大きくなり過ぎてオーバーフローすることを言い、モデルを不安定にします。勾配クリッピングは勾配が大きくなり過ぎることを防ぐために勾配を「クリップ」するかあるいはそれらを閾値に蓋をします (= cap)。これを回避するために、gradient_clip_val を設定できます (デフォルトは 0.0 に設定)。

[when to use it, what are relevant values]

trainer = pl.Trainer(gradient_clip_val=0.1)

trainer.fit(model, train_loader, val_loader)

 

truncated_bptt_steps

大規模なリカレント・モデルを持つ場合、シークエンスの部分に渡る backprop を分割するために truncated_bptt_steps フラグを利用できます。このフラグはバッチを自動的に truncate して trainer はそれに Truncated Backprop を適用します。

バッチがシークエンス次元を持つことを確実にしてください。

Lightning は時間次元に沿ってバッチを分割する対処をします。

# we use the second as the time dimension
# (batch, time, ...)
sub_batch = batch[0, 0:t, ...]
Using this feature requires updating your LightningModule’s pytorch_lightning.core.LightningModule.training_step() to include a hiddens arg with the hidden

# Truncated back-propagation through time
def training_step(self, batch, batch_idx, hiddens):
    # hiddens are the hiddens from the previous truncated backprop step
    out, hiddens = self.lstm(data, hiddens)

    return {
        "loss": ...,
        "hiddens": hiddens  # remember to detach() this
    }

# backprop every 5 steps in a batch
trainer = pl.Trainer(truncated_bptt_steps=5)

trainer.fit(model, train_loader, val_loader)

バッチがどのように分割されるかを変更するには、pytorch_lightning.core.LightningModule.tbptt_split_batch() を override します :

class LitMNIST(LightningModule):
    def tbptt_split_batch(self, batch, split_size):
        # do your own splitting on the batch
        return splits

 

reload_dataloaders_every_epoch

dataloader を総てのエポックで再ロードするには True に設定します (訓練の最初に一度だけロードする代わりに)。

# if False (default)
train_loader = model.train_dataloader()
for epoch in epochs:
    for batch in train_loader:
        ...

# if True
for epoch in epochs:
    train_loader = model.train_dataloader()
    for batch in train_loader:

trainer = pl.Trainer(reload_dataloaders_every_epoch=True)

trainer.fit(model, train_loader, val_loader)

 

コールバック

Lightning コールバックはプロジェクトに渡り再利用できる自己充足的なプログラムです。コールバックは貴方の LightningModule が実行されるために「必要ではない」非本質的な ロジックを捕捉するべきです。Lightning は幾つかの組込みコールバックを含みます、これらは early stopping とモデル・チェックポインティングのようにフラグとともに利用できますが、モデルに任意の機能を追加するために貴方自身のコールバックを作成することもできます。

コールバック API は訓練の総てのポイントでロジックを追加することを可能にするフックを含みます : setup, teardown, on_epoch_start, on_epoch_end, on_batch_start, on_batch_end, on_init_start, on_keyboard_interrupt 等。

 

callbacks

ユーザ定義コールバックのリストを渡すには callbacks= を使用します。これらのコールバックは組込みコールバック (loggers or EarlyStopping) は「置き換えません」。

このサンプルでは、on_train_start と on_train_end フックを使用して、訓練が開始されて終了するときメッセージをプリントするダミー・コールバックを作成します。

from pytorch_lightning.callbacks import Callback

class PrintCallback(Callback):
    def on_train_start(self, trainer, pl_module):
        print("Training is started!")
    def on_train_end(self, trainer, pl_module):
        print("Training is done.")

# a list of callbacks
callbacks = [PrintCallback()]
trainer = pl.Trainer(callbacks=callbacks)

trainer.fit(model, train_loader, val_loader)

 

モデル・チェックポインティング

チェックポイントはモデルにより使用される総てのパラメータの正確な値を捕捉します。訓練のチェックポインティングは訓練プロセスをそれが中断された場合に再開し、モデルを再調整したり (モデルを再訓練しなければならないことなく) 推論のために事前訓練モデルを利用します。

Lightning はチェックポイントのセーブとロードを自動化しますので、以下を含む総ての必要なパラメータをセーブして、訓練セッションをリストアします :

• 16-bit スケーリング因子 (apex)
• 現在のエポック
• グローバル・ステップ
• モデル state_dict
• 総ての optimizer の状態
• 総ての学習率スケジューラの状態
• 総てのコールバックの状態
• そのモデルのためのハイパーパラメータ、hparams (Argparse.Namespace) として渡される場合。

デフォルトでは Lightning は作業ディレクトリにチェックポイントをセーブします、これは毎エポック更新されます。

 

自動セービング

デフォルトでは Lightning は最初のエポックの後に作業ディレクトリにチェックポイントをセーブします、これは毎エポック更新されます。

# default used by the Trainer
trainer = pl.Trainer(default_root_dir=os.getcwd())

trainer.fit(model, train_loader, val_loader)

チェックポイント・パスを変更するには default_root_dir= を渡します :

trainer = pl.Trainer(default_root_dir='/your/path/to/save/checkpoints')

trainer.fit(model, train_loader, val_loader)

キーを monitor= に渡すことにより、(self.log を使用して) ロギングしている特定のメトリックに基づいて Lightning にチェックポイントを更新させることもできます。例えば、検証損失に基づいてチェックポイントをセーブすることを望む場合、以下を渡すことができます :

checkpoint_callback = ModelCheckpoint(
    filepath=os.getcwd(),
    save_top_k=1,
    verbose=True,
    monitor='val_loss',
    mode='min',
    prefix=''
)

from pytorch_lightning.callbacks import ModelCheckpoint

trainer = pl.Trainer(callbacks=[ModelCheckpoint(monitor='val_loss')])

trainer.fit(model, train_loader, val_loader)

貴方自身のコールバックを作成してそれを trainer に渡すことにより、チェックポインティングの動作を変更することができます。以下を制御できます :

• filepath – ログがどこにセーブされるか
• save_top_k – k top モデルをセーブする
• verbose
• monitor – 監視するメトリック
• mode
• prefix

from pytorch_lightning.callbacks import ModelCheckpoint

# DEFAULTS used by the Trainer
checkpoint_callback = ModelCheckpoint(
    filepath=os.getcwd(),
    save_top_k=3,
    verbose=True,
    monitor='val_loss',
    mode='min',
    prefix='',
)

trainer = Trainer(callbacks=[checkpoint_callback])

trainer.fit(model, train_loader, val_loader)

以下を渡すことによりそれをチェックポイントすることを無効にできます :

trainer = Trainer(checkpoint_callback=False)

 

手動セービング

手動でチェックポイントをセーブしてチェックポイントされた状態からモデルをリストアできます。

trainer.fit(model)
trainer.save_checkpoint("example.ckpt")
new_model = LitAutoEncoder.load_from_checkpoint(checkpoint_path="example.ckpt")

 

チェックポイント・ローディング

モデルをその重み、バイアスと module_arguments と一緒にロードするには次のメソッドを使用します :

model = LitAutoEncoder.load_from_checkpoint(PATH)

print(model.learning_rate)
# prints the learning_rate you used in this checkpoint

model.eval()
y_hat = model(x)

しかしもしチェックポイントにセーブされた値を使用することを望まない場合には、ここで貴方自身のものを渡してください :

class LitAutoEncoder(LightningModule):

    def __init__(self, in_dim, out_dim):
        super().__init__()
        self.save_hyperparameters()
        self.l1 = nn.Linear(self.hparams.in_dim, self.hparams.out_dim)

モデルをこのようにリストアできます :

# if you train and save the model like this it will use these values when loading
# the weights. But you can overwrite this
LitAutoEncoder(in_dim=32, out_dim=10)

# uses in_dim=32, out_dim=10
model = LitAutoEncoder.load_from_checkpoint(PATH)

# uses in_dim=128, out_dim=10
model = LitAutoEncoder.load_from_checkpoint(PATH, in_dim=128, out_dim=10)

 

訓練状態をリストアする (resume_from_checkpoint)

訓練が何らかの理由で切り上げられた場合、resume_from_checkpoint フラグを使用して貴方が去ったところから正確に再開できます、これはモデル、エポック、ステップ、LR スケジューラ、apex 等… を自動的にリストアします。

model = LitAutoEncoder()
trainer = pl.Trainer(resume_from_checkpoint='some/path/to/my_checkpoint.ckpt')

# automatically restores model, epoch, step, LR schedulers, apex, etc...
trainer.fit(model)

 

weights_save_path

weights_save_path を使用して重みファイルをセーブするためのディレクトリを指定できます。

(カスタム・チェックポイント・コールバックを使用している場合、チェックポイント・コールバックはこのフラグを override します。)

# save to your custom path
trainer = pl.Trainer(weights_save_path='my/path')

trainer.fit(model, train_loader, val_loader)

# if checkpoint callback used, then overrides the weights path
# **NOTE: this saves weights to some/path NOT my/path
checkpoint = ModelCheckpoint(filepath='some/path')
trainer = pl.Trainer(
    callbacks=[checkpoint],
    weights_save_path='my/path'
)
trainer.fit(model, train_loader, val_loader)

 

Early stopping

EarlyStopping コールバックは改良が観測できないとき、overfitting を回避するために検証メトリックを監視して訓練を停止するために使用できます。

Early Stopping を有効にするために EarlyStopping コールバックを初期化して、そしてそれを callbacks= trainer フラグに渡します。コールバックはその上で早期停止する、ログ記録されたメトリック求めます。

from pytorch_lightning.callbacks.early_stopping import EarlyStopping

trainer = pl.Trainer(callbacks=[EarlyStopping('val_loss')])

trainer.fit(model, train_loader, val_loader)

次の params を使用してコールバックをカスタマイズできます :

from pytorch_lightning.callbacks.early_stopping import EarlyStopping

early_stop_callback = EarlyStopping(
   monitor='val_accuracy',
   min_delta=0.00,
   patience=3,
   verbose=False,
   mode='max'
)
trainer = pl.Trainer(callbacks=[early_stop_callback])

trainer.fit(model, train_loader, val_loader)

EarlyStopping コールバックは総ての検証エポックの最後に実行されます、これはデフォルト構成では総ての訓練エポックの後に発生します。けれども、検証頻度は Trainer 上の様々なパラメータを設定することにより変更できます、例えば check_val_every_n_epoch と val_check_interval です。patience パラメータは改良のない検証エポックの数をカウントし、訓練エポックの数ではないことに注意しなければなりません。従って、パラメータ check_val_every_n_epoch=10 と patience=3 により、trainer は停止される前に少なくとも 40 訓練エポックを遂行します。

 

ロギング

Lightning は TensorBoard, wandb, commet 等のような様々なロガーと統合されています。

損失や精度のような、訓練の間に self.log にログ記録したい任意のメトリクスを渡すことができます。同様に、検証ステップの間にログ記録したい任意のメトリックを self.log に渡します。

これらの値は選択したロガーに渡されます。単純にサポートされるロガーに logger trainer フラグを渡します。

ロガーか、ロガーの iterable なコレクションに渡すために logger= trainer フラグを使用します、実験追跡のために。

from pytorch_lightning.loggers import TensorBoardLogger

# default logger used by trainer
logger = TensorBoardLogger(
    save_dir=os.getcwd(),
    version=1,
    name='lightning_logs'
)
trainer = pl.Trainer(logger=logger)

trainer.fit(model, train_loader, val_loader)

Lightning は複数のロガーの使用をサポートします、単にリストを Trainer に渡します。

from pytorch_lightning.loggers import TensorBoardLogger, TestTubeLogger
logger1 = TensorBoardLogger('tb_logs', name='my_model')
logger2 = TestTubeLogger('tb_logs', name='my_model')
trainer = pl.Trainer(logger=[logger1, logger2])

 

flush_logs_every_n_steps

disc へのロギングがいつ発生するべきかを決定するこのフラグを使用します。

trainer = pl.Trainer(flush_logs_every_n_steps=100)

trainer.fit(model, train_loader, val_loader)

 

log_every_n_steps

ロギング行をどれくらいの頻度で追加するか (ディスクには書きません)

trainer = pl.Trainer(log_every_n_steps=1000)

trainer.fit(model, train_loader, val_loader)

 

info ロギング

default_root_dir

Default path for logs and weights when no logger or pytorch_lightning.callbacks.ModelCheckpoint callback passed. あるクラスタではログとチェックポイントがストアされるところを分離することを望むかもしれません。If you don’t then use this argument for convenience. パスは s3://bucket/path or ‘hdfs://path/’ のようなローカルパスかリモートパスであり得ます。リモート・ファイルパスを使用するにはクレデンシャルがセットアップされる必要があります。

 

weights_summary

訓練が始まるとき重みの概要 (= summary) をプリントします。デフォルトは top に設定されます – トップレベル・モジュールの概要をプリントします。

オプション: ‘full’, ‘top’, None.

# print full summary of all modules and submodules
trainer = pl.Trainer(weights_summary='full')

trainer.fit(model, train_loader, val_loader)

# don't print a summary
trainer = Trainer(weights_summary=None)

trainer.fit(model, train_loader, val_loader)

 

progress bar (進捗バー)

process_position

進捗バーを順序付けます。同じノードで複数の trainer を実行するとき有用です。

(カスタム・コールバックが callbacks に渡される場合この引数は無視されます)

# default used by the Trainer
trainer = pl.Trainer(process_position=0)

trainer.fit(model, train_loader, val_loader)

 

progress_bar_refresh_rate

進捗バーをどのくらいの頻度でリフレッシュするか (in steps)。ノートブックでは、高速なリフレッシュレート (低い数) はスクリーン・リフレッシュレートのためにそれらをクラッシュすることが知られていますので、それを 50 かそれ以上に上げます。

# default used by the Trainer
trainer = pl.Trainer(progress_bar_refresh_rate=1)

trainer.fit(model, train_loader, val_loader)

# disable progress bar
trainer = Trainer(progress_bar_refresh_rate=0)

trainer.fit(model, train_loader, val_loader)

 

プロファイラー

# to profile standard training events
trainer = pl.Trainer(profiler=True)

trainer.fit(model, train_loader, val_loader)

与えられたアクションの間に記録された各関数呼び出しに消費された時間についてのより詳細な情報を望む場合 Lightning AdvancedProfiler を使用することもできます。出力は非常に verbose ですので非常に詳細なレポートを望む場合にのみこれを使用するべきです。

from pytorch_lightning.profiler import AdvancedProfiler

trainer = Trainer(profiler=AdvancedProfiler())

trainer.fit(model, train_loader, val_loader)

以上