fastai: a layered deep learning library on top of PyTorch

What fastai solves, and who it is for

Training a neural network in plain PyTorch means writing a training loop, a validation loop, a learning rate schedule and dataset plumbing before you see a first result. fastai packages those steps into high-level components that the README describes as providing "state-of-the-art results in standard deep learning domains" while keeping low-level components available for researchers. The audience is split in two. One group wants an image classifier, a text sentiment model, a segmentation model, a recommendation system or a tabular model with roughly five lines of code, as the Quick Start page shows. The other group wants to replace one piece of the pipeline, such as the optimizer or the data loading, without rewriting everything above and below it. The project is explicit that it tries to serve both without substantial compromises in ease of use, flexibility or performance.

The layered architecture and the abstractions behind it

fastai is organized as a hierarchy of lower-level APIs that expose composable building blocks. A user who wants to rewrite part of the high-level API does not have to learn the lowest level first. The README lists several mechanisms that make this work: a type dispatch system for Python with a semantic type hierarchy for tensors, a GPU-optimized computer vision library extendable in pure Python, an optimizer that factors modern optimization algorithms into two basic pieces so an algorithm can be implemented in four or five lines, and a two-way callback system that can read or change any part of the data, model or optimizer at any point during training. These are the parts that matter if you plan to modify training behaviour rather than just call fit. The data block API is the other structural piece, and it is what the tutorials build on when you bring your own dataset. The repository itself is mostly notebooks: the top level contains nbs/ and dev_nbs/, and the project uses nbdev, so documentation and tests are generated from notebooks rather than written separately.

Installing fastai and training a first model

The README gives two installation paths. The first avoids installation entirely: every page of the documentation is an interactive notebook, and the "Open in colab" link at the top of a page opens it in Google Colab, where you should switch the runtime to GPU. The second is a normal package install, with the recommendation to install PyTorch first so you get the best available version for your machine.

pip install fastai

If you want to develop fastai itself, the README describes an editable install, and notes that you should use an editable install of fastcore alongside it.

git clone https://github.com/fastai/fastai
pip install -e "fastai[dev]"

The pyproject.toml declares requires-python >=3.10 and a torch dependency of torch>=1.10,<3, so a Python 3.9 environment will not satisfy the package metadata. For a container-based setup, the repository ships a docker-compose.yml that builds a notebook service from the fastai/codespaces image, mounts the repository at /data and exposes port 8080.

services:
  notebook:
    image: fastai/codespaces
    ports:
      - "8080:8080"

That service runs pip install -e on the value of LIB_INSTALL_TYPE, which defaults to "." in the compose file, and starts Jupyter with the token and password disabled, so it is a local development convenience rather than something to expose on a network.

Windows, num_workers and the Jupyter slowdown

The README documents a concrete failure mode rather than hiding it. Because of Python multiprocessing issues on Jupyter and Windows, num_workers of the DataLoader is reset to 0 automatically to avoid Jupyter hanging. The consequence is stated plainly: computer vision tasks in Jupyter on Windows are many times slower than on Linux. The limitation does not apply when you use fastai from a script, and the repository includes an example, nbs/examples/dataloader_spawn.py, for using the API on Windows. The project recommends Windows Subsystem for Linux instead, where the regular Linux installation applies and num_workers behaves normally. This is the clearest case where fastai is the wrong tool: an interactive Windows notebook workflow for image data will run at a fraction of the speed of the same code on Linux, and no configuration flag in the library removes the underlying multiprocessing problem.

Migrating from plain PyTorch, Ignite, Lightning or Catalyst

fastai is built on PyTorch, so the alternative to compare it against is not a different framework but a different amount of structure. The README states that migration from plain PyTorch, Ignite or any other PyTorch-based library is easy, and that you can generally keep existing data processing code while reducing the training code and picking up modern best practices. It links migration guides for plain PyTorch, Ignite, Lightning and Catalyst. The difference in approach is where the abstraction sits. With plain PyTorch you own the training loop and every schedule inside it. With Lightning you keep a loop but organize it inside a module class with hooks. fastai instead gives you a Learner with callbacks, and the two-way callback system is the extension point: you attach behaviour that can inspect or modify the model, data or optimizer at any point in training rather than subclassing a fixed lifecycle. That is a real design difference, not a cosmetic one, and it is why the library can claim both a five-line quick start and a hackable lower layer.

Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-09, with releases 2.8.12, 2.8.11 and 2.8.10 all published within the same week. The changelog lives at CHANGELOG.md at the top level, which is where to look before upgrading a pinned version. The dependency list is broad: fastcore, fasttransform, fastdownload, torchvision, torch, spacy, scikit-learn, scipy, pandas, pillow, matplotlib and plum-dispatch, among others. Several are pinned with upper bounds, including fastdownload<2, spacy<4 and plum-dispatch<2.10, so a minor release of one of those can block an upgrade until fastai widens the constraint. The dev extra is much larger and pulls in lightning, pytorch-ignite, transformers, catalyst, timm, accelerate and others, which is relevant only if you install the editable dev path. fastai is licensed under Apache-2.0, as stated in both the README metadata and pyproject.toml. That is a permissive licence, but it is not legal advice: if you redistribute fastai inside a product, read the licence text and the licences of its dependencies yourself, since Apache-2.0 does not cover the transitive packages.

Editorial conclusion

fastai suits practitioners who want working image, text, tabular or recommendation models without writing training loops, and researchers who want to swap layers of the stack. It is a poor fit if you need a non-PyTorch backend or cannot tolerate the Windows DataLoader limitation. Before adopting it, check that your Python is 3.10 or newer, that your PyTorch version satisfies the torch>=1.10,<3 constraint, and whether the conda channel or pip install fastai path matches your environment.

Frequently asked questions

Official sources

1. fastai/fastai on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases