Loading

A core premise of the diffusers library is to make diffusion models as accessible as possible. Accessibility is therefore achieved by providing an API to load complete diffusion pipelines as well as individual components with a single line of code.

In the following we explain in-detail how to easily load:

• Complete Diffusion Pipelines via the DiffusionPipeline.from_pretrained()
• Diffusion Models via ModelMixin.from_pretrained()
• Schedulers via SchedulerMixin.from_pretrained()

Loading pipelines

The DiffusionPipeline class is the easiest way to access any diffusion model that is available on the Hub. Let’s look at an example on how to download Runway’s Stable Diffusion model.

from diffusers import DiffusionPipeline

repo_id = "runwayml/stable-diffusion-v1-5"
pipe = DiffusionPipeline.from_pretrained(repo_id)

Here DiffusionPipeline automatically detects the correct pipeline (i.e. StableDiffusionPipeline), downloads and caches all required configuration and weight files (if not already done so), and finally returns a pipeline instance, called pipe. The pipeline instance can then be called using StableDiffusionPipeline.call() (i.e., pipe("image of a astronaut riding a horse")) for text-to-image generation.

Instead of using the generic DiffusionPipeline class for loading, you can also load the appropriate pipeline class directly. The code snippet above yields the same instance as when doing:

from diffusers import StableDiffusionPipeline

repo_id = "runwayml/stable-diffusion-v1-5"
pipe = StableDiffusionPipeline.from_pretrained(repo_id)

from diffusers import StableDiffusionImg2ImgPipeline

repo_id = "runwayml/stable-diffusion-v1-5"
pipe = StableDiffusionImg2ImgPipeline.from_pretrained(repo_id)

Diffusion pipelines like StableDiffusionPipeline or StableDiffusionImg2ImgPipeline consist of multiple components. These components can be both parameterized models, such as "unet", "vae" and "text_encoder", tokenizers or schedulers. These components often interact in complex ways with each other when using the pipeline in inference, e.g. for StableDiffusionPipeline the inference call is explained here. The purpose of the pipeline classes is to wrap the complexity of these diffusion systems and give the user an easy-to-use API while staying flexible for customization, as will be shown later.

Loading pipelines locally

If you prefer to have complete control over the pipeline and its corresponding files or, as said before, if you want to use pipelines that require an access request without having to be connected to the Hugging Face Hub, we recommend loading pipelines locally.

To load a diffusion pipeline locally, you first need to manually download the whole folder structure on your local disk and then pass a local path to the DiffusionPipeline.from_pretrained(). Let’s again look at an example for Runway’s Stable Diffusion Diffusion model.

First, you should make use of git-lfs to download the whole folder structure that has been uploaded to the model repository:

git lfs install
git clone https://huggingface.co/runwayml/stable-diffusion-v1-5

The command above will create a local folder called ./stable-diffusion-v1-5 on your disk. Now, all you have to do is to simply pass the local folder path to from_pretrained:

from diffusers import DiffusionPipeline

repo_id = "./stable-diffusion-v1-5"
stable_diffusion = DiffusionPipeline.from_pretrained(repo_id)

If repo_id is a local path, as it is the case here, DiffusionPipeline.from_pretrained() will automatically detect it and therefore not try to download any files from the Hub. While we usually recommend to load weights directly from the Hub to be certain to stay up to date with the newest changes, loading pipelines locally should be preferred if one wants to stay anonymous, self-contained applications, etc…

Loading customized pipelines

Advanced users that want to load customized versions of diffusion pipelines can do so by swapping any of the default components, e.g. the scheduler, with other scheduler classes. A classical use case of this functionality is to swap the scheduler. Stable Diffusion v1-5 uses the PNDMScheduler by default which is generally not the most performant scheduler. Since the release of stable diffusion, multiple improved schedulers have been published. To use those, the user has to manually load their preferred scheduler and pass it into DiffusionPipeline.from_pretrained().

E.g. to use EulerDiscreteScheduler or DPMSolverMultistepScheduler to have a better quality vs. generation speed trade-off for inference, one could load them as follows:

from diffusers import DiffusionPipeline, EulerDiscreteScheduler, DPMSolverMultistepScheduler

repo_id = "runwayml/stable-diffusion-v1-5"

scheduler = EulerDiscreteScheduler.from_pretrained(repo_id, subfolder="scheduler")
# or
# scheduler = DPMSolverMultistepScheduler.from_pretrained(repo_id, subfolder="scheduler")

stable_diffusion = DiffusionPipeline.from_pretrained(repo_id, scheduler=scheduler)

Three things are worth paying attention to here.

• First, the scheduler is loaded with SchedulerMixin.from_pretrained()
• Second, the scheduler is loaded with a function argument, called subfolder="scheduler" as the configuration of stable diffusion’s scheduling is defined in a subfolder of the official pipeline repository
• Third, the scheduler instance can simply be passed with the scheduler keyword argument to DiffusionPipeline.from_pretrained(). This works because the StableDiffusionPipeline defines its scheduler with the scheduler attribute. It’s not possible to use a different name, such as sampler=scheduler since sampler is not a defined keyword for StableDiffusionPipeline.__init__()

Not only the scheduler components can be customized for diffusion pipelines; in theory, all components of a pipeline can be customized. In practice, however, it often only makes sense to switch out a component that has compatible alternatives to what the pipeline expects. Many scheduler classes are compatible with each other as can be seen here. This is not always the case for other components, such as the "unet".

One special case that can also be customized is the "safety_checker" of stable diffusion. If you believe the safety checker doesn’t serve you any good, you can simply disable it by passing None:

from diffusers import DiffusionPipeline, EulerDiscreteScheduler, DPMSolverMultistepScheduler

stable_diffusion = DiffusionPipeline.from_pretrained(repo_id, safety_checker=None)

Another common use case is to reuse the same components in multiple pipelines, e.g. the weights and configurations of "runwayml/stable-diffusion-v1-5" can be used for both StableDiffusionPipeline and StableDiffusionImg2ImgPipeline and we might not want to use the exact same weights into RAM twice. In this case, customizing all the input instances would help us to only load the weights into RAM once:

from diffusers import StableDiffusionPipeline, StableDiffusionImg2ImgPipeline

model_id = "runwayml/stable-diffusion-v1-5"
stable_diffusion_txt2img = StableDiffusionPipeline.from_pretrained(model_id)

components = stable_diffusion_txt2img.components

# weights are not reloaded into RAM
stable_diffusion_img2img = StableDiffusionImg2ImgPipeline(**components)

Note how the above code snippet makes use of DiffusionPipeline.components.

Loading variants

Diffusion Pipeline checkpoints can offer variants of the “main” diffusion pipeline checkpoint. Such checkpoint variants are usually variations of the checkpoint that have advantages for specific use-cases and that are so similar to the “main” checkpoint that they should not be put in a new checkpoint. A variation of a checkpoint has to have exactly the same serialization format and exactly the same model structure, including all weights having the same tensor shapes.

Examples of variations are different floating point types and non-ema weights. I.e. “fp16”, “bf16”, and “no_ema” are common variations.

Let's first talk about whats **not** checkpoint variant,

Checkpoint variants do not include different serialization formats (such as safetensors) as weights in different serialization formats are identical to the weights of the “main” checkpoint, just loaded in a different framework.

Also variants do not correspond to different model structures, e.g. stable-diffusion-v1-5 is not a variant of stable-diffusion-2-0 since the model structure is different (Stable Diffusion 1-5 uses a different CLIPTextModel compared to Stable Diffusion 2.0).

Pipeline checkpoints that are identical in model structure, but have been trained on different datasets, trained with vastly different training setups and thus correspond to different official releases (such as Stable Diffusion v1-4 and Stable Diffusion v1-5) should probably be stored in individual repositories instead of as variations of eachother.

So what are checkpoint variants then?

Checkpoint variants usually consist of the checkpoint stored in ”low-precision, low-storage” dtype so that less bandwith is required to download them, or of non-exponential-averaged weights that shall be used when continuing fine-tuning from the checkpoint. Both use cases have clear advantages when their weights are considered variants: they share the same serialization format as the reference weights, and they correspond to a specialization of the “main” checkpoint which does not warrant a new model repository. A checkpoint stored in torch’s half-precision / float16 format requires only half the bandwith and storage when downloading the checkpoint, but cannot be used when continuing training or when running the checkpoint on CPU. Similarly the non-exponential-averaged (or non-EMA) version of the checkpoint should be used when continuing fine-tuning of the model checkpoint, but should not be used when using the checkpoint for inference.

How to save and load variants

Saving a diffusion pipeline as a variant can be done by providing DiffusionPipeline.save_pretrained() with the variant argument. The variant extends the weight name by the provided variation, by changing the default weight name from diffusion_pytorch_model.bin to diffusion_pytorch_model.{variant}.bin or from diffusion_pytorch_model.safetensors to diffusion_pytorch_model.{variant}.safetensors. By doing so, one creates a variant of the pipeline checkpoint that can be loaded instead of the “main” pipeline checkpoint.

Let’s have a look at how we could create a float16 variant of a pipeline. First, we load the “main” variant of a checkpoint (stored in float32 precision) into mixed precision format, using torch_dtype=torch.float16.

from diffusers import DiffusionPipeline
import torch

pipe = DiffusionPipeline.from_pretrained("runwayml/stable-diffusion-v1-5", torch_dtype=torch.float16)

Now all model components of the pipeline are stored in half-precision dtype. We can now save the pipeline under a "fp16" variant as follows:

pipe.save_pretrained("./stable-diffusion-v1-5", variant="fp16")

If we don’t save into an existing stable-diffusion-v1-5 folder the new folder would look as follows:

stable-diffusion-v1-5
├── feature_extractor
│   └── preprocessor_config.json
├── model_index.json
├── safety_checker
│   ├── config.json
│   └── pytorch_model.fp16.bin
├── scheduler
│   └── scheduler_config.json
├── text_encoder
│   ├── config.json
│   └── pytorch_model.fp16.bin
├── tokenizer
│   ├── merges.txt
│   ├── special_tokens_map.json
│   ├── tokenizer_config.json
│   └── vocab.json
├── unet
│   ├── config.json
│   └── diffusion_pytorch_model.fp16.bin
└── vae
    ├── config.json
    └── diffusion_pytorch_model.fp16.bin

As one can see, all model files now have a .fp16.bin extension instead of just .bin. The variant now has to be loaded by also passing a variant="fp16" to DiffusionPipeline.from_pretrained(), e.g.:

DiffusionPipeline.from_pretrained("./stable-diffusion-v1-5", variant="fp16", torch_dtype=torch.float16)

works just fine, while:

DiffusionPipeline.from_pretrained("./stable-diffusion-v1-5", torch_dtype=torch.float16)

throws an Exception:

OSError: Error no file named diffusion_pytorch_model.bin found in directory ./stable-diffusion-v1-45/vae since we **only** stored the model 

This is expected as we don’t have any “non-variant” checkpoint files saved locally. However, the whole idea of pipeline variants is that they can co-exist with the “main” variant, so one would typically also save the “main” variant in the same folder. Let’s do this:

pipe = DiffusionPipeline.from_pretrained("runwayml/stable-diffusion-v1-5")
pipe.save_pretrained("./stable-diffusion-v1-5")

and upload the pipeline to the Hub under diffusers/stable-diffusion-variants. The file structure on the Hub now looks as follows:

├── feature_extractor
│   └── preprocessor_config.json
├── model_index.json
├── safety_checker
│   ├── config.json
│   ├── pytorch_model.bin
│   └── pytorch_model.fp16.bin
├── scheduler
│   └── scheduler_config.json
├── text_encoder
│   ├── config.json
│   ├── pytorch_model.bin
│   └── pytorch_model.fp16.bin
├── tokenizer
│   ├── merges.txt
│   ├── special_tokens_map.json
│   ├── tokenizer_config.json
│   └── vocab.json
├── unet
│   ├── config.json
│   ├── diffusion_pytorch_model.bin
│   ├── diffusion_pytorch_model.fp16.bin
└── vae
    ├── config.json
    ├── diffusion_pytorch_model.bin
    └── diffusion_pytorch_model.fp16.bin

We can now both download the “main” and the “fp16” variant from the Hub. Both:

pipe = DiffusionPipeline.from_pretrained("diffusers/stable-diffusion-variants")

and

pipe = DiffusionPipeline.from_pretrained("diffusers/stable-diffusion-variants", variant="fp16")

works.

Finally, there are cases where only some of the checkpoint files of the pipeline are of a certain variation. E.g. it’s usually only the UNet checkpoint that has both a exponential-mean-averaged (EMA) and a non-exponential-mean-averaged (non-EMA) version. All other model components, e.g. the text encoder, safety checker or variational auto-encoder usually don’t have such a variation. In such a case, one would upload just the UNet’s checkpoint file with a non_ema version format (as done here) and upon calling:

pipe = DiffusionPipeline.from_pretrained("diffusers/stable-diffusion-variants", variant="non_ema")

the model will use only the “non_ema” checkpoint variant if it is available - otherwise it’ll load the “main” variation. In the above example, variant="non_ema" would therefore download the following file structure:

├── feature_extractor
│   └── preprocessor_config.json
├── model_index.json
├── safety_checker
│   ├── config.json
│   ├── pytorch_model.bin
├── scheduler
│   └── scheduler_config.json
├── text_encoder
│   ├── config.json
│   ├── pytorch_model.bin
├── tokenizer
│   ├── merges.txt
│   ├── special_tokens_map.json
│   ├── tokenizer_config.json
│   └── vocab.json
├── unet
│   ├── config.json
│   └── diffusion_pytorch_model.non_ema.bin
└── vae
    ├── config.json
    ├── diffusion_pytorch_model.bin

In a nutshell, using variant="{variant}" will download all files that match the {variant} and if for a model component such a file variant is not present it will download the “main” variant. If neither a “main” or {variant} variant is available, an error will the thrown.

How does loading work?

As a class method, DiffusionPipeline.from_pretrained() is responsible for two things:

• Download the latest version of the folder structure required to run the repo_id with diffusers and cache them. If the latest folder structure is available in the local cache, DiffusionPipeline.from_pretrained() will simply reuse the cache and not re-download the files.
• Load the cached weights into the correct pipeline class – one of the officially supported pipeline classes - and return an instance of the class. The correct pipeline class is thereby retrieved from the model_index.json file.

The underlying folder structure of diffusion pipelines correspond 1-to-1 to their corresponding class instances, e.g. StableDiffusionPipeline for runwayml/stable-diffusion-v1-5 This can be better understood by looking at an example. Let’s load a pipeline class instance pipe and print it:

from diffusers import DiffusionPipeline

repo_id = "runwayml/stable-diffusion-v1-5"
pipe = DiffusionPipeline.from_pretrained(repo_id)
print(pipe)

Output:

StableDiffusionPipeline {
  "feature_extractor": [
    "transformers",
    "CLIPFeatureExtractor"
  ],
  "safety_checker": [
    "stable_diffusion",
    "StableDiffusionSafetyChecker"
  ],
  "scheduler": [
    "diffusers",
    "PNDMScheduler"
  ],
  "text_encoder": [
    "transformers",
    "CLIPTextModel"
  ],
  "tokenizer": [
    "transformers",
    "CLIPTokenizer"
  ],
  "unet": [
    "diffusers",
    "UNet2DConditionModel"
  ],
  "vae": [
    "diffusers",
    "AutoencoderKL"
  ]
}

First, we see that the official pipeline is the StableDiffusionPipeline, and second we see that the StableDiffusionPipeline consists of 7 components:

• "feature_extractor" of class CLIPFeatureExtractor as defined in transformers.
• "safety_checker" as defined here.
• "scheduler" of class PNDMScheduler.
• "text_encoder" of class CLIPTextModel as defined in transformers.
• "tokenizer" of class CLIPTokenizer as defined in transformers.
• "unet" of class UNet2DConditionModel.
• "vae" of class AutoencoderKL.

Let’s now compare the pipeline instance to the folder structure of the model repository runwayml/stable-diffusion-v1-5. Looking at the folder structure of runwayml/stable-diffusion-v1-5 on the Hub and excluding model and saving format variants, we can see it matches 1-to-1 the printed out instance of StableDiffusionPipeline above:

.
├── feature_extractor
│   └── preprocessor_config.json
├── model_index.json
├── safety_checker
│   ├── config.json
│   └── pytorch_model.bin
├── scheduler
│   └── scheduler_config.json
├── text_encoder
│   ├── config.json
│   └── pytorch_model.bin
├── tokenizer
│   ├── merges.txt
│   ├── special_tokens_map.json
│   ├── tokenizer_config.json
│   └── vocab.json
├── unet
│   ├── config.json
│   ├── diffusion_pytorch_model.bin
└── vae
    ├── config.json
    ├── diffusion_pytorch_model.bin

Each attribute of the instance of StableDiffusionPipeline has its configuration and possibly weights defined in a subfolder that is called exactly like the class attribute ("feature_extractor", "safety_checker", "scheduler", "text_encoder", "tokenizer", "unet", "vae"). Importantly, every pipeline expects a model_index.json file that tells the DiffusionPipeline both:

• which pipeline class should be loaded, and
• what sub-classes from which library are stored in which subfolders

In the case of runwayml/stable-diffusion-v1-5 the model_index.json is therefore defined as follows:

{
  "_class_name": "StableDiffusionPipeline",
  "_diffusers_version": "0.6.0",
  "feature_extractor": [
    "transformers",
    "CLIPFeatureExtractor"
  ],
  "safety_checker": [
    "stable_diffusion",
    "StableDiffusionSafetyChecker"
  ],
  "scheduler": [
    "diffusers",
    "PNDMScheduler"
  ],
  "text_encoder": [
    "transformers",
    "CLIPTextModel"
  ],
  "tokenizer": [
    "transformers",
    "CLIPTokenizer"
  ],
  "unet": [
    "diffusers",
    "UNet2DConditionModel"
  ],
  "vae": [
    "diffusers",
    "AutoencoderKL"
  ]
}

• _class_name tells DiffusionPipeline which pipeline class should be loaded.
• _diffusers_version can be useful to know under which diffusers version this model was created.
• Every component of the pipeline is then defined under the form:

"name" : [
  "library",
  "class"
]

• The "name" field corresponds both to the name of the subfolder in which the configuration and weights are stored as well as the attribute name of the pipeline class (as can be seen here and here
• The "library" field corresponds to the name of the library, e.g. diffusers or transformers from which the "class" should be loaded
• The "class" field corresponds to the name of the class, e.g. CLIPTokenizer or UNet2DConditionModel

Loading models

Models as defined under src/diffusers/models can be loaded via the ModelMixin.from_pretrained() function. The API is very similar the DiffusionPipeline.from_pretrained() and works in the same way:

• Download the latest version of the model weights and configuration with diffusers and cache them. If the latest files are available in the local cache, ModelMixin.from_pretrained() will simply reuse the cache and not re-download the files.
• Load the cached weights into the defined model class - one of the existing model classes - and return an instance of the class.

In constrast to DiffusionPipeline.from_pretrained(), models rely on fewer files that usually don’t require a folder structure, but just a diffusion_pytorch_model.bin and config.json file.

Let’s look at an example:

from diffusers import UNet2DConditionModel

repo_id = "runwayml/stable-diffusion-v1-5"
model = UNet2DConditionModel.from_pretrained(repo_id, subfolder="unet")

Note how we have to define the subfolder="unet" argument to tell ModelMixin.from_pretrained() that the model weights are located in a subfolder of the repository.

As explained in Loading customized pipelines, one can pass a loaded model to a diffusion pipeline, via DiffusionPipeline.from_pretrained():

from diffusers import DiffusionPipeline

repo_id = "runwayml/stable-diffusion-v1-5"
pipe = DiffusionPipeline.from_pretrained(repo_id, unet=model)

If the model files can be found directly at the root level, which is usually only the case for some very simple diffusion models, such as google/ddpm-cifar10-32, we don’t need to pass a subfolder argument:

from diffusers import UNet2DModel

repo_id = "google/ddpm-cifar10-32"
model = UNet2DModel.from_pretrained(repo_id)

As motivated in How to save and load variants?, models can load and save variants. To load a model variant, one should pass the variant function argument to ModelMixin.from_pretrained(). Analogous, to save a model variant, one should pass the variant function argument to ModelMixin.save_pretrained():

from diffusers import UNet2DConditionModel

model = UNet2DConditionModel.from_pretrained(
    "diffusers/stable-diffusion-variants", subfolder="unet", variant="non_ema"
)
model.save_pretrained("./local-unet", variant="non_ema")

Loading schedulers

Schedulers rely on SchedulerMixin.from_pretrained(). Schedulers are not parameterized or trained, but instead purely defined by a configuration file. For consistency, we use the same method name as we do for models or pipelines, but no weights are loaded in this case.

In constrast to pipelines or models, loading schedulers does not consume any significant amount of memory and the same configuration file can often be used for a variety of different schedulers. For example, all of:

• DDPMScheduler
• DDIMScheduler
• PNDMScheduler
• LMSDiscreteScheduler
• EulerDiscreteScheduler
• EulerAncestralDiscreteScheduler
• DPMSolverMultistepScheduler

are compatible with StableDiffusionPipeline and therefore the same scheduler configuration file can be loaded in any of those classes:

from diffusers import StableDiffusionPipeline
from diffusers import (
    DDPMScheduler,
    DDIMScheduler,
    PNDMScheduler,
    LMSDiscreteScheduler,
    EulerDiscreteScheduler,
    EulerAncestralDiscreteScheduler,
    DPMSolverMultistepScheduler,
)

repo_id = "runwayml/stable-diffusion-v1-5"

ddpm = DDPMScheduler.from_pretrained(repo_id, subfolder="scheduler")
ddim = DDIMScheduler.from_pretrained(repo_id, subfolder="scheduler")
pndm = PNDMScheduler.from_pretrained(repo_id, subfolder="scheduler")
lms = LMSDiscreteScheduler.from_pretrained(repo_id, subfolder="scheduler")
euler_anc = EulerAncestralDiscreteScheduler.from_pretrained(repo_id, subfolder="scheduler")
euler = EulerDiscreteScheduler.from_pretrained(repo_id, subfolder="scheduler")
dpm = DPMSolverMultistepScheduler.from_pretrained(repo_id, subfolder="scheduler")

# replace `dpm` with any of `ddpm`, `ddim`, `pndm`, `lms`, `euler`, `euler_anc`
pipeline = StableDiffusionPipeline.from_pretrained(repo_id, scheduler=dpm)