01 · Why Lightning? 🤔

5 min read

Before you learn a new tool, you should be able to say exactly what problem it solves. For Lightning, that problem is boilerplate — and you've felt it yourself.

1. The 'Why'

You've now written the same training loop half a dozen times across this course, and if you laid those loops side by side you'd see an uncomfortable truth: 80% of the code is identical every time. The outer epoch loop, the optimizer.zero_grad() → forward → loss → backward → optimizer.step() sequence, moving each batch to the device, flipping between model.train() and model.eval(), running a validation pass, tracking metrics, saving the best checkpoint — this scaffolding is the same whether you're training a tiny MLP or a Transformer. It's boilerplate: essential to make things run, but not where your actual ideas live. And because it's repetitive and manual, it's a magnet for subtle, silent bugs — a forgotten zero_grad, a validation loop that never called eval(), a batch left on the wrong device.

The problem compounds as your ambitions grow. Want to train on multiple GPUs? Use mixed precision to train faster? Log to TensorBoard? Resume from a checkpoint on preemption? Each of these means more fiddly, error-prone code threaded through your loop, and getting any of it wrong can quietly degrade or break training. PyTorch Lightning exists to absorb all of that. It's a thin framework that takes the boilerplate off your hands — writing it once, correctly, tested by thousands of users — while leaving you in charge of the parts that are genuinely yours: the model, the loss, the optimizer, the data. Understanding this division of labor is the whole point of this sub-module: Lightning isn't magic and it isn't a new way to think about deep learning; it's disciplined organization of the PyTorch you already know.

2. Core Concepts

Boilerplate vs. research code. Research code is what's unique to your problem: the model architecture, the loss, the optimizer choice, what happens to a batch. Engineering/boilerplate is the loop mechanics, device placement, precision, distribution, logging. Lightning's core idea is to separate the two and automate the second.

Lightning organizes, it doesn't replace. Your model stays an nn.Module; your data stays DataLoaders; your tensors and autograd are unchanged. You restructure your existing code into defined methods, and Lightning calls them at the right time.

What Lightning automates for free. The epoch/batch loops, zero_grad/backward/step, train()/eval() switching, moving data to the device, 16-bit mixed precision, multi-GPU/TPU, logging, and checkpointing — all via configuration rather than hand-written code.

What you keep control of. What the model computes, how loss is calculated, which optimizer runs, and what your data is. Lightning never hides these from you.

The two main classes. The LightningModule (sub-module 02) holds your model + step logic; the Trainer (sub-module 03) runs it. That's the whole mental model.

3. Code in Action

The boilerplate you keep rewriting (raw PyTorch)

# Every module so far has repeated essentially THIS:
for epoch in range(epochs):
    model.train()
    for X, y in train_loader:
        X, y = X.to(device), y.to(device)     # device plumbing
        optimizer.zero_grad()                 # boilerplate
        loss = criterion(model(X), y)
        loss.backward()                       # boilerplate
        optimizer.step()                      # boilerplate
    model.eval()                              # boilerplate
    with torch.no_grad():                     # boilerplate
        for X, y in val_loader:
            X, y = X.to(device), y.to(device)
            ...                               # metric tracking, checkpointing, ...

Installing Lightning

pip install lightning         # the modern package name (imported as `lightning`)
# (older code may use `pip install pytorch-lightning` / `import pytorch_lightning`)

The same job, reorganized (preview)

import lightning as L

# You'll write these two pieces (details in sub-modules 02–03):
#   class LitModel(L.LightningModule): ...   <- your model + step logic, NO loop
#   trainer = L.Trainer(max_epochs=10)       <- runs everything above for you
#   trainer.fit(model, train_loader, val_loader)
# The device moves, zero_grad, backward, step, eval() switching — all handled.

4. Common Pitfalls

Pitfall 1 — Thinking Lightning is a different framework. It isn't. If you try to "learn Lightning" without your PyTorch fundamentals, you'll be lost. Lightning is organized PyTorch — the loop you already understand, relocated into methods. Your Module 01–08 knowledge transfers directly.

Pitfall 2 — Reaching for it too early. Lightning shines once you understand what it automates. Learning it before you can write a loop by hand hides bugs and stunts understanding — which is exactly why this course put it in Module 09, not Module 05.

Pitfall 3 — Package/name confusion. The project was renamed: the modern install is pip install lightning with import lightning as L, while lots of older tutorials use pytorch_lightning. They're the same lineage; just be consistent within a project to avoid import errors.

5. Further Reading & Watch List

➡️ Next: 02 · The LightningModule