[docs] Simplify loading guide

[stevhliu]

This PR moves the high-level explanations in the loading guide into a separate Conceptual Guide so users can focus on executing the code more quickly. The explanatory guide is linked for users who are interested in learning more about what's happening.

[HuggingFaceDocBuilderDev]

The documentation is not available anymore as the PR was closed or merged.

[stevhliu]

This is just a draft because I have some questions about variants :)

[sayakpaul]

Nice cleanup!

I really like the new "explained" doc. But I would request @patrickvonplaten to take a closer look in case I missed anything.

[patrickvonplaten]

Hmm not too happy about the changes here. I see the benefit of simplifying the loading doc - however all the info that is deleted is very important for users. I don't think we should do a split (loading / conceptual guide here). I think we should leave everything on the loading page (which is visited a lot) and just split everything into "basic" and "advanced" use cases.

I don't think it makes sense to add a now "explanatory guide" here. IMO many users just want a quick look-up they can visit quickly to see how variants work instead of having to read through a guide/tutorial.

I see loading much closer to API doc string that is looked up a lot instead of something like a tutorial.

[stevhliu]

Thanks for the feedback!

I've refactored to keep everything on one page (I'll delete the "explained" page once we're happy with this), and split it into practical stuff at the top and explanatory things at the bottom. I think the practical steps are important for the quick look-up without necessarily needing to know how the folder is structured and the details of the model_index.json file, for example.

But if they are interested, I added a <Tip> where they can skip to the end and get more context about how it works.

I think all the info should still be on the page, but feel free to let me know if I'm missing anything!

[patrickvonplaten]

Ready for final review @stevhliu - should we move out of draft mode?

[patrickvonplaten]

Looks nice! Could we just add some more specification about the difference between variant and torch_dtype?

[patrickvonplaten]

Here we need to be more precise I think.

variant -> this just defines what files should be loaded
torch_dtype -> this defines into what torch_dtype the weights should be converted to.

Can we maybe try to say something along the following:

Suggested change

	Load a variant by specifying the `variant` argument in [`DiffusionPipeline.from_pretrained`], and the `torch_dtype` if the variant is a different floating point type. 🧨 Diffusers won't download a variant unless it is explicitly specified, so you don't have to worry about downloading and caching more checkpoints than you need.
	Load a variant by specifying the `variant` argument in [`DiffusionPipeline.from_pretrained`]. 🧨 Diffusers won't download a variant unless it is explicitly specified, so you don't have to worry about unnecessarily downloading and caching more checkpoints than you need.
	The `torch_dtype` argument is unrelated to the `variant` argument and decides which floating point precision the loaded checkpoints should have. If you want to save bandwidth by loading a `"fp16"` variant, you should also define `torch_dtype=torch.float16` as otherwise the fp16 weights will be converted to the default fp32 precision. Note that you can also load the original checkpoint without setting a variant and then converting it to float16 precision by passing `torch_dtype=torch.float16`. In this case you downloaded float32 weights and converted them to float16 after loading.

[patrickvonplaten]

It would be great if the reader could understand the difference between torch_dtype and variant here (they are completely orthogonal.

[stevhliu]

Thanks for the explanation, this is super helpful!

[patrickvonplaten]

Looks good to me!