MONAI: a PyTorch framework for healthcare imaging, and where it stops

What MONAI solves for medical imaging teams

General-purpose computer vision libraries assume 2D images with three colour channels and a fixed orientation. Medical volumes arrive as 3D or 4D arrays with anisotropic spacing, arbitrary orientation codes, and intensity ranges that differ per scanner. MONAI exists to fill that gap. The README describes it as a PyTorch-based open-source framework for deep learning in healthcare imaging, part of the PyTorch Ecosystem, with the stated ambition of creating end-to-end training workflows for healthcare imaging and giving researchers a standardized way to build and evaluate models. The audience is explicit in the project metadata: the classifiers list Developers, Education, Science/Research and Healthcare Industry. This is a library for people who train models, not a viewer, not an annotation tool, and not a diagnostic device. The repository topics (deep-learning, healthcare-imaging, medical-image-computing, medical-image-processing, monai, python3, pytorch) match that positioning. If your problem is segmenting CT volumes, classifying 2D slices from a public dataset such as MedNIST, or running the same training script across several GPUs, MONAI is aimed at you. If your problem is getting a radiologist to label a study, MONAI itself does not answer it.

The mechanism: composable transforms over PyTorch tensors

MONAI is not a new training loop. The README lists its features as flexible pre-processing for multi-dimensional medical imaging data, compositional and portable APIs for integration into existing workflows, domain-specific implementations for networks, losses and evaluation metrics, customizable design for varying user expertise, and multi-GPU multi-node data parallelism support. Read that list as an architecture statement. The framework supplies pieces that plug into a PyTorch pipeline: transforms that operate on arrays and dictionaries of arrays, loss functions written for class-imbalanced segmentation, metrics that handle the label conventions of medical data, and network implementations. Because the APIs are described as compositional, the intended pattern is to chain them rather than to adopt a monolithic trainer. Two consequences follow. First, your existing PyTorch code stays in charge of the optimization loop, so the cost of trying MONAI is bounded. Second, the framework's value concentrates in the transform and metric layers, which is exactly where generic libraries are weakest for volumetric data. The repository layout supports this reading: the package lives under monai/ with a tests/ directory beside it, and the project ships a pyproject.toml listing torch and numpy as its only direct dependencies, with everything else optional. That optionality is deliberate. The README notes MONAI depends directly on NumPy and PyTorch with many optional dependencies, and points to pyproject.toml for version information.

Installing MONAI and running a first transform

The README gives one command for the current release. It pulls the package from PyPI along with its declared dependencies, torch and numpy.

pip install monai

After that, the README points to two Colab notebooks for a first run: a MedNIST demo for 2D classification and a MONAI for PyTorch Users guide. The repository also carries a Dockerfile and a Dockerfile.slim, and the README documents the published image. The image is tagged latest for the latest state of dev or with a release version, and the documented start command is:

docker run -ti --rm --gpus all projectmonai/monai:latest /bin/bash

The --gpus all flag means this path expects an NVIDIA container runtime; on a machine without a GPU, drop that flag or use the pip route. Note what the Dockerfile shows about how the image is built: it starts from an NVIDIA PyTorch base image and sets BUILD_MONAI=1, and setup.py only compiles the C++ and CUDA extensions when that environment variable equals 1. So a plain pip install gets you the Python package without the compiled extensions, while the container is built with them. For a first real use, follow the README's own direction rather than inventing a pipeline: open the MedNIST notebook, which is the documented entry point, and confirm that the transforms and the training loop run end to end on the sample data before pointing MONAI at your own volumes.

Version pinning is the main operational cost

The dependency policy is unusually explicit, and it is the part most likely to bite. The README states that MONAI works with currently supported versions of Python, that major releases have dependency versions stated for them, and that the dev branch is the unreleased development version which typically supports current dependency versions. PyTorch support covers the current version plus three previous minor versions. Other dependencies follow SPEC0 for the most part, with versions supported where possible for up to two years, and the README adds that discovered vulnerabilities or defects may require certain versions to be explicitly not supported. In practice this means the supported window moves. If you pin an old PyTorch for a validated model, you can fall outside the covered range without any change on your side. The pyproject.toml confirms the floor: torch>=2.8.0 and numpy>=1.24,<3.0, with requires-python >=3.10. The numpy upper bound is worth noting because it will force an upgrade decision when numpy 3.x arrives. Monorepo-style upgrades are also a factor: the README points to weekly previews published as monai-weekly, distinct from the monai package, so a team can end up with two versions installed in different environments. The README does not document a rollback procedure or a long-term support branch, and the CHANGELOG.md in the repository root is the place to check what changed between releases.

Where MONAI is the wrong tool

MONAI is a training and evaluation library. It does not ship a DICOM viewer, an annotation interface, or a deployment runtime, and the README does not claim otherwise. Two boundaries matter most. First, annotation and interactive segmentation: the README links to MONAI Label only through the broader project ecosystem, and the search interest in using MONAI Label inside 3D Slicer reflects a workflow that lives in separate projects, not in this repository. If your bottleneck is getting labels, installing monai will not address it. Second, clinical use: nothing in the README, the pyproject.toml classifiers, or the repository entries describes regulatory clearance, prospective validation, or a deployment pathway. The Healthcare Industry classifier signals intended audience, not certification. There is also a practical ceiling on convenience. The README describes the design as customizable for varying user expertise, which is honest but also a warning: the compositional API means you assemble the pipeline, and the documentation you need is spread across the readthedocs site, the tutorials repository, and the bundle format documentation. Teams expecting a batteries-included trainer with sane defaults will spend time reading rather than training. Finally, the build story has a sharp edge for anyone who needs the compiled extensions: setup.py only builds them when BUILD_MONAI=1, and the FORCE_CUDA flag is documented in that file as ignored when BUILD_MONAI is false.

How MONAI differs from plain PyTorch and TorchIO

The honest alternative is not a competing framework but the combination most teams already use: PyTorch plus a medical imaging I/O and augmentation library. TorchIO occupies that space, providing PyTorch-native loading and augmentation for medical images. The difference in approach is scope. TorchIO concentrates on reading and augmenting volumes; MONAI bundles transforms, domain-specific networks, losses, evaluation metrics, and multi-GPU multi-node data parallelism in one project, and the README frames the whole thing as end-to-end training workflows. That breadth is the reason to choose MONAI and also the reason it is heavier. A team that already has a working augmentation pipeline and only needs a Dice-based loss has little reason to adopt the full framework. A team starting from scratch on 3D segmentation, or one that wants the MONAI Bundle format so a model can be shared through the MONAI Model Zoo, gets more from the integrated stack. A second alternative is to use PyTorch alone and write the medical-specific transforms yourself. That is viable for a narrow pipeline, and it keeps your dependency surface at two packages instead of a framework with optional extras. The trade-off is maintenance: you own the orientation handling, spacing logic and metric implementations, and you own their correctness.

Licence and maintenance signals

MONAI is released under the Apache License 2.0, stated in the LICENSE file, in the pyproject.toml license field, and in the README badge. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices; the repository also carries CITATION.cff and asks researchers to cite the project, with the citation exportable from arXiv 2211.02701. Citation is a request, not a licence condition, so it does not restrict commercial use of the code. What Apache-2.0 does not cover is your model weights, your training data, or any regulatory obligation attached to a clinical product; nothing in the repository speaks to those. On maintenance, the repository is not archived and the last push was on 2026-09-10. The most recent release listed is 1.6.0 on 2026-06-11, preceded by 1.5.2 on 2026-01-29 and 1.5.1 on 2025-09-22. That is a release cadence of roughly two to three minor or patch releases per year, with development activity on the dev branch between them. The practical upgrade cost is the dependency window described above: each release can move the supported PyTorch and Python versions, so an upgrade is a real test cycle rather than a version bump. The repository provides a runtests.sh script and a tests/ directory, which is where you would look before upgrading.

Editorial conclusion

Adopt MONAI if you already train PyTorch models on 3D or multimodal medical images and want domain-specific transforms, losses, metrics and multi-GPU data parallelism without writing them yourself. Do not adopt it as a clinical deployment or annotation product: MONAI Label and 3D Slicer integration sit in separate projects, and the README does not describe a regulatory or deployment path. Before committing, check the pyproject.toml dependency pins against your installed PyTorch, confirm the release you plan to use on PyPI, and read the installation guide for the optional extras your pipeline needs.

Frequently asked questions

Official sources

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