Populate torch_dtype from model to pipeline

[B-Step62]

What does this PR do?

When constructing a pipeline from a model, it doesn't inherit the torch_dtype attribute from the model's dtype. This causes asymmetry of pipeline and model, as the model always inherit the torch_dtype when the pipeline is created with torch_dtype param. Sometimes it's a bit confusing that the pipeline's torch_dtype is None (which could mislead the dtype is default one), while the underlying model has different dtype.
Therefore, this PR updates the pipeline construction logic to set torch_dtype attribute on pipeline based on model's dtype.

Fixes #28817

Before submitting

• This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
• Did you read the contributor guideline,
  Pull Request section?
• Was this discussed/approved via a Github issue or the forum? Please add a link
  to it if that's the case.
• Did you make sure to update the documentation with your changes? Here are the
  documentation guidelines, and
  here are tips on formatting docstrings.
• Did you write any new necessary tests?

Who can review?

@ArthurZucker @Rocketknight1

[ArthurZucker]

dtype of the model is subject to changes. A property might be a lot simpler 😉

[B-Step62]

@ArthurZucker Sorry for my extremely late response...🙇

Using property to handle model dtype update makes sense. Revised the logic as such so would appreciate if you could take another look. Thanks!

[ArthurZucker]

Alright LGTM, but I think we should just always return the dtype of the model

[ArthurZucker]

I don't really agree here, we should always return the dtype of the model just for consistence. The pipeline should error out normally and we should not assume that None torch_dtype == not supported

[B-Step62]

I agree with the consistency concern, but also wonder that the model's dtype doesn't always translate to torch_dtype, like a model loaded with tensorflow/jax backend. If that sounds ok, I will proceed with simply propagating the model dtype:)

[ArthurZucker]

If you have a FlaxLlamaModel then accessing the dtype should just be consistent imo

[B-Step62]

@ArthurZucker Make sense, I found that TFPretrainedModel doesn't have dtype property so my concern is not the case. My apologies for misunderstanding!
I've updated the code so would appreciate if you could take another look, thanks!

[ArthurZucker]

Sorry was off for a week !

[ArthurZucker]

Thanks for iterating!

[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.

[B-Step62]

@ArthurZucker Sorry for bothering you repeated times. I found an issue in this change.

I found that TFPretrainedModel doesn't have dtype property so my concern is not the case.

I've just tested a few models and turned out this is no accurate. TFPretrainedModel inherits dtype property from keras.Layer. Its value is not pytorch dtype so returning model dtype as torch_dtype property is inaccurate imo.

I think there are a few workaround,

1. Check the type of model.dtype or not, and return nothing if it isn't torch.dtype.
2. Check the model is instance of TFPretrainedModel and return nothing if so.
3. Rename the property from torch_dtype to dtype.

I think the first one is most convenient for users, but please let me know your thoughts!

[ArthurZucker]

That would be a new feature! Given that before there were no dtype. It's not super necessary but yeah we can add a new one

[B-Step62]

Yeah if the first option sounds good I'm happy to file a follow-up PR now before this change is released. I think it's more proper behavior for torch_dtype property (and what its type annotation says:)).