Flux Autoencoder

[calvinpelletier]

Context

What is the purpose of this PR? Is it to

• add a new feature
• fix a bug
• update tests and/or documentation
• other (please add here)

Please link to any issues this PR addresses.

Changelog

What are the changes made in this PR?

• Implement the Flux autoencoder model
• Function to convert weights from HF's format to ours
• Unit tests

Test plan

Please make sure to do each of the following if applicable to your PR. If you're unsure about any one of these just ask and we will happily help. We also have a contributing page for some guidance on contributing.

• run pre-commit hooks and linters (make sure you've first installed via pre-commit install)
• add unit tests for any new functionality
• update docstrings for any new or updated methods or classes
• run unit tests via pytest tests
• run recipe tests via pytest tests -m integration_test
• manually run any new or modified recipes with sufficient proof of correctness
• include relevant commands and any other artifacts in this summary (pastes of loss curves, eval results, etc.)

Parity: 3.36e-5

Speed: ~10% faster

Mnimal testing code:

import numpy as np
import torch
from PIL import Image
from safetensors.torch import load_file

from torchtune.models.flux import flux_autoencoder
from torchtune.models.flux._convert_weights import flux_ae_hf_to_tune

# First, download the AE weights: https://github.com/black-forest-labs/flux/blob/main/src/flux/util.py#L373
WEIGHTS_PATH = "/home/cpelletier/.cache/huggingface/hub/models--black-forest-labs--FLUX.1-dev/snapshots/0ef5fff789c832c5c7f4e127f94c8b54bbcced44/ae.safetensors"


def to_img(x):
    x = x.clamp(-1, 1).float()
    x = x[0].permute(1, 2, 0)
    return Image.fromarray((127.5 * (x + 1.0)).cpu().byte().numpy())


def to_tensor(img):
    img = img.resize((256, 256), Image.Resampling.LANCZOS)
    x = np.array(img, dtype=np.float32)
    x = (x / 127.5) - 1.0
    x = torch.from_numpy(x)
    x = x.permute(2, 0, 1).unsqueeze(0)
    return x.cuda().to(dtype=torch.bfloat16)


ae = flux_autoencoder()
ae.load_state_dict(flux_ae_hf_to_tune(load_file(WEIGHTS_PATH)))
ae = ae.to(dtype=torch.bfloat16, device="cuda").eval().requires_grad_(False)

x = to_tensor(Image.open("/home/cpelletier/tmp.jpg"))
y = ae(x)
to_img(y).save("/home/cpelletier/out.png")

UX

If your function changed a public API, please add a dummy example of what the user experience will look like when calling it.
Here is a docstring example
and a tutorial example

• I did not change any public API
• I have added an example to docs or docstrings

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/torchtune/2098

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

As of commit aa8b751 with merge base 32e265d ():
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[calvinpelletier]

Should this be a model builder or component builder?

Also, should it be named flux_v1_autoencoder, anticipating future flux versions? Or just flux_autoencoder, anticipating that the autoencoder part probably won't change in the next version?

[pbontrager]

Yes I think the name flux_1_autoencoder would be good. If doesn't make sense to break Autoencoder into smaller components, then there's no need for a component builder.

[pbontrager]

This looks really good. A few minor things to followup on and I'll approve

[pbontrager]

Yes I think the name flux_1_autoencoder would be good. If doesn't make sense to break Autoencoder into smaller components, then there's no need for a component builder.

[pbontrager]

Small thing, we follow the pattern of looping through the list of layers here instead of putting them into Sequential. This makes the forward pass a bit more readable and easier to add breakpoints.

[pbontrager]

Can we name these FluxDecoder/FluxEncoder?

[pbontrager]

This is a bit of overkill now, but I'd have the FluxAutoencoder just take in an Enocder and Decoder as inputs and then define a component builder function to define Encoder + Decoder and pass them into Autoencoder. This does nothing for us now, but if we want to add lora support for the autoencoder in the future it'll make it much easier.

[pbontrager]

These are from the small dummy model, did you run these same tests on the full model with weights against the flux codebase?