Sana: eight model families and one pinned Python package

Eight model families share one repository and one distribution

The repository is not a single model. Its own description calls SANA an efficiency-oriented codebase for high-resolution image and video generation, providing complete training and inference pipelines, and the top level shows how wide that is: sana/, diffusion/, app/, configs/, train_scripts/, train_video_scripts/, inference_video_scripts/, tools/, scripts/, tests/ and docs/. The front page then points at eight separate codebases inside that tree, namely SANA, SANA-1.5, SANA-Sprint, SANA-Video, SANA-Video 2.0, SANA-WM, SANA-Streaming and Sol-RL. The packaging metadata declares one distribution named sana at version 0.2.0,.

Setup runs through environment_setup.sh, not a pip install line

The repository has environment_setup.sh at the top level, plus a Dockerfile that copies the pieces and runs it:

COPY pyproject.toml pyproject.toml
COPY diffusion diffusion
COPY configs configs
COPY sana sana
COPY app app
COPY tools tools

COPY environment_setup.sh environment_setup.sh
RUN ./environment_setup.sh

Before that the Dockerfile installs libgl1-mesa-glx and libglib2.0-0 with apt-get, places Miniconda under /opt/conda, and sets WORKDIR /app. If you work outside that container, read environment_setup.sh first, since the Dockerfile only runs it.

The container default command opens a public share link

The last line of the Dockerfile defines what the image does when started with no arguments, and it is worth reading before you build anything:

CMD ["python", "-u", "-W", "ignore", "app/app_sana.py", "--share", "--config=configs/sana_config/1024ms/Sana_1600M_img1024.yaml", "--model_path=hf://Efficient-Large-Model/Sana_1600M_1024px/checkpoints/Sana_1600M_1024px.pth"]

Three consequences follow from that single line. The entry point is a Python app under app/, not a training script. The weights arrive over the Hugging Face hub through an hf:// path instead of being baked into the image. And `--share` publishes the interface to an external share endpoint, which is wrong for anything you intend to keep private. The two console scripts the package declares are separate entry points:

[project.scripts]
sana-run = "sana.cli.run:main"
sana-upload = "sana.cli.upload2hf:main"

The dependency list pins the whole PyTorch stack and blocks a shared env

Python 3.11 or newer is required, and the core ML packages in the dependency block are exact pins: torch==2.9.1, torchvision==0.24.1, torchaudio==2.9.1, mmcv==1.7.2, timm==0.6.13, transformers==4.57.3, xformers==0.0.33.post2, triton==3.5.1, peft==0.18.0, huggingface-hub==0.36.0 and pre-commit==4.5.0. Most other packages are left open or unversioned, including diffusers>=0.37.0, accelerate>=1.3, flash-linear-attention>=0.4.2, gradio and einops, and an extra index for CUDA-specific PyTorch wheels is configured:

[tool.pip]
extra-index-url = ["https://download.pytorch.org/whl/cu128"]

That combination will not install into an environment already holding different versions of any of those packages, so a shared virtualenv with other PyTorch work is out. The base image is tagged 24.06 while torch tracks a much later release line, so treat the image and dependency pairing as something to check against your own driver rather than assume.

pyproject says 0.2.0 while the release tags read 2.0.0

Two version schemes describe this project and they never meet. The package metadata reads:

[project]
name = "sana"
version = "0.2.0"
description = "SANA"
readme = "README.md"
requires-python = ">=3.11"

The release history includes v1.5.0 and v2.0.0, and the tags carry their own names: v1.5.0 covers SANA-1.5 and SANA-Sprint, and v2.0.0 covers SANA-Video and SANA-WM. Nothing in the tree connects the two schemes, so a version check written against the installed distribution tells you nothing about which model line you are holding. Pin your checkpoint by its path from the model zoo rather than by package version, and record the two separately in your own notes.

Each release tag spans two families, and weights lag the training code

Both version tags bundle more than one family, which is the repository's most awkward habit. v1.5.0 is labelled SANA-1.5 && SANA-Sprint and v2.0.0 is labelled SANA-Video && SANA-WM, so a tag marks a snapshot of two code paths rather than one artifact. The news entries repeat the problem in another form. SANA-WM Stage-1 training landed in 2026/07, two months after the 2.6B controllable world model in 2026/05, and SANA-Streaming training landed in 2026/07 while the 2B streaming editing model had already shipped in 2026/06. Training code and model weights arrive on separate dates with no shared version marker.

One mkdocs site and one Discord serve eight projects

mkdocs.yml and docs/ sit beside eight project pages, and the front page links each family to its own location under nvlabs.github.io with general documentation at /Sana/docs/. Support is centralised too: a single Discord invite, with ComfyUI_ExtraModels, SGLang and Cosmos-RL listed as the routes for community model loading, serving and RL post-training. The cost of that concentration is that the repository cannot point you at the right page until you know which family you are running, and none of those integration targets is covered by its own dependency list. Sol-RL, for instance, releases training recipes for SANA, FLUX.1 and SD3.5-L with bundled post-training datasets, which is a wider surface than a single pinned environment can absorb at once. The news list also names hardware from GB200 down to a DGX Spark and a GeForce RTX 5090, so the same code is expected to run far from a data centre.

Editorial conclusion

Sana is worth your time if you need training and inference code for a specific family, the world model with 6-DoF camera control, or the streaming editing model, and it is a poor fit if you want a library you can drop into an existing environment, because the core PyTorch dependencies are exact pins and the distribution version tells you nothing about which checkpoint you loaded. Before you start, read environment_setup.sh yourself, decide whether the container or your own virtualenv is the target, and pin your weights by path rather than by tag.

Frequently asked questions

Official sources

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