2020-05-05 02:16:54 +00:00
|
|
|
.. testsetup:: *
|
|
|
|
|
|
|
|
from pytorch_lightning.core.lightning import LightningModule
|
|
|
|
from pytorch_lightning.trainer.trainer import Trainer
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-07 05:23:48 +00:00
|
|
|
Quick Start
|
|
|
|
===========
|
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
PyTorch Lightning is nothing more than organized PyTorch code.
|
|
|
|
Once you've organized it into a LightningModule, it automates most of the training for you.
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
To illustrate, here's the typical PyTorch project structure organized in a LightningModule.
|
|
|
|
|
|
|
|
.. figure:: /_images/mnist_imgs/pt_to_pl.jpg
|
|
|
|
:alt: Convert from PyTorch to Lightning
|
|
|
|
|
|
|
|
|
|
|
|
Step 1: Define a LightningModule
|
|
|
|
---------------------------------
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-05-05 02:16:54 +00:00
|
|
|
.. testcode::
|
|
|
|
:skipif: not TORCHVISION_AVAILABLE
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
import os
|
|
|
|
|
|
|
|
import torch
|
|
|
|
from torch.nn import functional as F
|
|
|
|
from torch.utils.data import DataLoader
|
|
|
|
from torchvision.datasets import MNIST
|
|
|
|
from torchvision import transforms
|
2020-05-05 02:16:54 +00:00
|
|
|
from pytorch_lightning.core.lightning import LightningModule
|
2020-04-26 14:57:26 +00:00
|
|
|
|
2020-05-05 02:16:54 +00:00
|
|
|
class LitModel(LightningModule):
|
2020-04-26 14:57:26 +00:00
|
|
|
|
|
|
|
def __init__(self):
|
|
|
|
super().__init__()
|
|
|
|
self.l1 = torch.nn.Linear(28 * 28, 10)
|
|
|
|
|
|
|
|
def forward(self, x):
|
|
|
|
return torch.relu(self.l1(x.view(x.size(0), -1)))
|
2019-12-07 05:23:48 +00:00
|
|
|
|
|
|
|
def training_step(self, batch, batch_idx):
|
2020-04-26 14:57:26 +00:00
|
|
|
x, y = batch
|
|
|
|
y_hat = self(x)
|
|
|
|
loss = F.cross_entropy(y_hat, y)
|
|
|
|
tensorboard_logs = {'train_loss': loss}
|
|
|
|
return {'loss': loss, 'log': tensorboard_logs}
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
def configure_optimizers(self):
|
|
|
|
return torch.optim.Adam(self.parameters(), lr=0.001)
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
def train_dataloader(self):
|
|
|
|
dataset = MNIST(os.getcwd(), train=True, download=True, transform=transforms.ToTensor())
|
|
|
|
loader = DataLoader(dataset, batch_size=32, num_workers=4, shuffle=True)
|
|
|
|
return loader
|
2019-12-07 05:23:48 +00:00
|
|
|
|
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
Step 2: Fit with a Trainer
|
|
|
|
--------------------------
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-05-05 02:16:54 +00:00
|
|
|
.. testcode::
|
|
|
|
:skipif: torch.cuda.device_count() < 8
|
2020-04-26 14:57:26 +00:00
|
|
|
|
|
|
|
from pytorch_lightning import Trainer
|
|
|
|
|
|
|
|
model = LitModel()
|
|
|
|
|
|
|
|
# most basic trainer, uses good defaults
|
|
|
|
trainer = Trainer(gpus=8, num_nodes=1)
|
|
|
|
trainer.fit(model)
|
|
|
|
|
2020-04-26 15:06:36 +00:00
|
|
|
Under the hood, lightning does (in high-level pseudocode):
|
2019-12-07 05:23:48 +00:00
|
|
|
|
|
|
|
.. code-block:: python
|
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
model = LitModel()
|
2020-05-05 02:16:54 +00:00
|
|
|
train_dataloader = model.train_dataloader()
|
2020-04-26 14:57:26 +00:00
|
|
|
optimizer = model.configure_optimizers()
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
for epoch in epochs:
|
|
|
|
train_outs = []
|
|
|
|
for batch in train_dataloader:
|
2020-05-05 02:16:54 +00:00
|
|
|
loss = model.training_step(batch)
|
2020-04-26 14:57:26 +00:00
|
|
|
loss.backward()
|
|
|
|
train_outs.append(loss.detach())
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
optimizer.step()
|
|
|
|
optimizer.zero_grad()
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
# optional for logging, etc...
|
|
|
|
model.training_epoch_end(train_outs)
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
Validation loop
|
|
|
|
---------------
|
|
|
|
To also add a validation loop add the following functions
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-05-05 02:16:54 +00:00
|
|
|
.. testcode::
|
2020-04-26 14:57:26 +00:00
|
|
|
|
2020-05-05 02:16:54 +00:00
|
|
|
class LitModel(LightningModule):
|
2020-04-26 14:57:26 +00:00
|
|
|
|
|
|
|
def validation_step(self, batch, batch_idx):
|
|
|
|
x, y = batch
|
|
|
|
y_hat = self(x)
|
|
|
|
return {'val_loss': F.cross_entropy(y_hat, y)}
|
|
|
|
|
|
|
|
def validation_epoch_end(self, outputs):
|
|
|
|
avg_loss = torch.stack([x['val_loss'] for x in outputs]).mean()
|
|
|
|
tensorboard_logs = {'val_loss': avg_loss}
|
2020-04-30 11:58:42 +00:00
|
|
|
return {'val_loss': avg_loss, 'log': tensorboard_logs}
|
2020-04-26 14:57:26 +00:00
|
|
|
|
|
|
|
def val_dataloader(self):
|
|
|
|
# TODO: do a real train/val split
|
|
|
|
dataset = MNIST(os.getcwd(), train=False, download=True, transform=transforms.ToTensor())
|
|
|
|
loader = DataLoader(dataset, batch_size=32, num_workers=4)
|
|
|
|
return loader
|
|
|
|
|
|
|
|
And now the trainer will call the validation loop automatically
|
|
|
|
|
|
|
|
.. code-block:: python
|
|
|
|
|
|
|
|
# most basic trainer, uses good defaults
|
|
|
|
trainer = Trainer(gpus=8, num_nodes=1)
|
|
|
|
trainer.fit(model)
|
|
|
|
|
|
|
|
Under the hood in pseudocode, lightning does the following:
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-05-05 02:16:54 +00:00
|
|
|
.. testsetup:: *
|
|
|
|
|
|
|
|
train_dataloader = []
|
|
|
|
|
|
|
|
.. testcode::
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
# ...
|
|
|
|
for batch in train_dataloader:
|
|
|
|
loss = model.training_step()
|
|
|
|
loss.backward()
|
|
|
|
# ...
|
|
|
|
|
|
|
|
if validate_at_some_point:
|
|
|
|
model.eval()
|
|
|
|
val_outs = []
|
|
|
|
for val_batch in model.val_dataloader:
|
|
|
|
val_out = model.validation_step(val_batch)
|
|
|
|
val_outs.append(val_out)
|
|
|
|
|
|
|
|
model.validation_epoch_end(val_outs)
|
|
|
|
model.train()
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
The beauty of Lightning is that it handles the details of when to validate, when to call .eval(),
|
|
|
|
turning off gradients, detaching graphs, making sure you don't enable shuffle for val, etc...
|
|
|
|
|
2020-04-26 15:06:36 +00:00
|
|
|
.. note:: Lightning removes all the million details you need to remember during research
|
2020-04-26 14:57:26 +00:00
|
|
|
|
|
|
|
Test loop
|
|
|
|
---------
|
|
|
|
You might also need a test loop
|
|
|
|
|
2020-05-05 02:16:54 +00:00
|
|
|
.. testcode::
|
2020-04-26 14:57:26 +00:00
|
|
|
|
2020-05-05 02:16:54 +00:00
|
|
|
class LitModel(LightningModule):
|
2020-04-26 14:57:26 +00:00
|
|
|
|
|
|
|
def test_step(self, batch, batch_idx):
|
|
|
|
x, y = batch
|
|
|
|
y_hat = self(x)
|
|
|
|
return {'test_loss': F.cross_entropy(y_hat, y)}
|
|
|
|
|
|
|
|
def test_epoch_end(self, outputs):
|
|
|
|
avg_loss = torch.stack([x['test_loss'] for x in outputs]).mean()
|
|
|
|
tensorboard_logs = {'test_loss': avg_loss}
|
|
|
|
return {'avg_test_loss': avg_loss, 'log': tensorboard_logs}
|
|
|
|
|
|
|
|
def test_dataloader(self):
|
|
|
|
# TODO: do a real train/val split
|
|
|
|
dataset = MNIST(os.getcwd(), train=False, download=True, transform=transforms.ToTensor())
|
|
|
|
loader = DataLoader(dataset, batch_size=32, num_workers=4)
|
|
|
|
return loader
|
|
|
|
|
|
|
|
However, this time you need to specifically call test (this is done so you don't use the test set by mistake)
|
|
|
|
|
|
|
|
.. code-block:: python
|
|
|
|
|
|
|
|
# OPTION 1:
|
|
|
|
# test after fit
|
2019-12-07 05:23:48 +00:00
|
|
|
trainer.fit(model)
|
2020-04-26 14:57:26 +00:00
|
|
|
trainer.test()
|
|
|
|
|
|
|
|
# OPTION 2:
|
|
|
|
# test after loading weights
|
|
|
|
model = LitModel.load_from_checkpoint(PATH)
|
|
|
|
trainer = Trainer(num_tpu_cores=1)
|
|
|
|
trainer.test()
|
|
|
|
|
|
|
|
Again, under the hood, lightning does the following in (pseudocode):
|
|
|
|
|
|
|
|
.. code-block:: python
|
|
|
|
|
|
|
|
model.eval()
|
|
|
|
test_outs = []
|
|
|
|
for test_batch in model.test_dataloader:
|
|
|
|
test_out = model.test_step(val_batch)
|
|
|
|
test_outs.append(test_out)
|
|
|
|
|
|
|
|
model.test_epoch_end(test_outs)
|
|
|
|
|
|
|
|
Datasets
|
|
|
|
--------
|
|
|
|
If you don't want to define the datasets as part of the LightningModule, just pass them into fit instead.
|
|
|
|
|
|
|
|
.. code-block:: python
|
|
|
|
|
|
|
|
# pass in datasets if you want.
|
|
|
|
train_dataloader = DataLoader(dataset, batch_size=32, num_workers=4)
|
|
|
|
val_dataloader, test_dataloader = ...
|
|
|
|
|
|
|
|
trainer = Trainer(gpus=8, num_nodes=1)
|
|
|
|
trainer.fit(model, train_dataloader, val_dataloader)
|
|
|
|
|
|
|
|
trainer.test(test_dataloader=test_dataloader)
|
|
|
|
|
|
|
|
The advantage of this method is the ability to reuse models for different datasets. The disadvantage
|
|
|
|
is that for research it makes readability and reproducibility more difficult. This is why we recommend
|
|
|
|
to define the datasets in the LightningModule if you're doing research, but use the method above for
|
|
|
|
production models or for prediction tasks.
|
|
|
|
|
|
|
|
Why do you need Lightning?
|
|
|
|
--------------------------
|
|
|
|
Notice the code above has nothing about .cuda() or 16-bit or early stopping or logging, etc...
|
|
|
|
This is where Lightning adds a ton of value.
|
|
|
|
|
|
|
|
Without changing a SINGLE line of your code, you can now do the following with the above code
|
|
|
|
|
|
|
|
.. code-block:: python
|
|
|
|
|
|
|
|
# train on TPUs using 16 bit precision with early stopping
|
|
|
|
# using only half the training data and checking validation every quarter of a training epoch
|
|
|
|
trainer = Trainer(
|
|
|
|
nb_tpu_cores=8,
|
|
|
|
precision=16,
|
|
|
|
early_stop_checkpoint=True,
|
|
|
|
train_percent_check=0.5,
|
|
|
|
val_check_interval=0.25
|
|
|
|
)
|
|
|
|
|
|
|
|
# train on 256 GPUs
|
|
|
|
trainer = Trainer(
|
|
|
|
gpus=8,
|
|
|
|
num_nodes=32
|
|
|
|
)
|
|
|
|
|
|
|
|
# train on 1024 CPUs across 128 machines
|
|
|
|
trainer = Trainer(
|
|
|
|
num_processes=8,
|
|
|
|
num_nodes=128
|
|
|
|
)
|
|
|
|
|
|
|
|
And the best part is that your code is STILL just PyTorch... meaning you can do anything you
|
|
|
|
would normally do.
|
|
|
|
|
|
|
|
.. code-block:: python
|
|
|
|
|
|
|
|
model = LitModel()
|
|
|
|
model.eval()
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
y_hat = model(x)
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
model.anything_you_can_do_with_pytorch()
|
2019-12-07 05:23:48 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
Summary
|
|
|
|
-------
|
|
|
|
In short, by refactoring your PyTorch code:
|
2020-01-17 11:03:31 +00:00
|
|
|
|
2020-04-26 14:57:26 +00:00
|
|
|
1. You STILL keep pure PyTorch.
|
|
|
|
2. You DON't lose any flexibility.
|
|
|
|
3. You can get rid of all of your boilerplate.
|
|
|
|
4. You make your code generalizable to any hardware.
|
|
|
|
5. Your code is now readable and easier to reproduce (ie: you help with the reproducibility crisis).
|
|
|
|
6. Your LightningModule is still just a pure PyTorch module.
|