[Tests] adds fast tests for single-file checkpoint loaders

[sayakpaul]

What does this PR do?

Fixes #6515.

[sayakpaul]

I don't think there's any other sane way for us to verify this.

[DN6]

Can't we add this into the test module? Why have it in src if it's only relevant to tests? We can pass it in using Pipeline.from_single_file(original_config_file="<file url>"). original_config_file can be a URL now.

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[sayakpaul]

@DN6 I dug a bit deeper into this today and I think it's better NOT to add tests for this yet. This is because there's a reliance on convert_diffusers_to_original_*.py which has way to many variables:

• Config file (I managed to create one here)
• Heuristics based on the original SD checkpoints (such as number of attention blocks, resnet blocks, etc. which different from the Tiny SD checkpoints quite a bit)

Both the above aspects heavily influence (and they should) how we craft our logic for single-file checkpoint loading.

Since single-file checkpoints are quite heavily used in diffusers I am hesitant to touch the codebase for rejigging the heuristics and potentially complicate the logic of what already works.

Do you agree to my reasoning?

[DN6]

@sayakpaul That's cool with me. So the core issue is that the current from_single_file logic is very rigid to the model structure of the original config because of how we currently map diffusers keys to ldm keys.

We can put a brief pause on this while we figure out a more robust way to do the mappings. I can take a look into how to make from_single_file more general so we can add these tests.

[sayakpaul]

So the core issue is that the current from_single_file logic is very rigid to the model structure of the original config because of how we currently map diffusers keys to ldm keys.

Yes exactly.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the contributing guidelines are likely to be ignored.

[sayakpaul]

Closing in favor of #7496.