noamaanMulla-03/transformers-issues huggingface dataset:
Add support for causal language modeling for `DistilBertModel`
Author: kingyiusuen
Pull request: no
Labels: name: Feature request

### Feature request

HuggingFace Transformers currently supports causal language modeling (CLM) fine-tuning for BERT using`BertLMHeadModel` [as shown in the docs](https://huggingface.co/docs/transformers/model_doc/bert#transformers.BertLMHeadModel). My request is simply to extend this support to `DistilBertModel`.

### Motivation

I want to use a distilBERT model to initialize a `EncoderDecoderModel`, but I am getting an error message that says it does not support CLM.

```python
from transformers import EncoderDecoderModel

EncoderDecoderModel.from_encoder_decoder_pretrained(
  encoder_pretrained_model_name_or_path="distilbert/distilbert-base-multilingual-cased",
  decoder_pretrained_model_name_or_path="distilbert/distilbert-base-multilingual-cased",
)
```

Here is the error message:

```
ValueError: Unrecognized configuration class <class 'transformers.models.distilbert.configuration_distilbert.DistilBertConfig'> for this kind of AutoModel: AutoModelForCausalLM.
Model type should be one of BartConfig, BertConfig, BertGenerationConfig, BigBirdConfig, BigBirdPegasusConfig, BioGptConfig, BlenderbotConfig, BlenderbotSmallConfig, BloomConfig, CamembertConfig, LlamaConfig, CodeGenConfig, CohereConfig, CpmAntConfig, CTRLConfig, Data2VecTextConfig, DbrxConfig, ElectraConfig, ErnieConfig, FalconConfig, FuyuConfig, GemmaConfig, Gemma2Config, GitConfig, GPT2Config, GPT2Config, GPTBigCodeConfig, GPTNeoConfig, GPTNeoXConfig, GPTNeoXJapaneseConfig, GPTJConfig, JambaConfig, JetMoeConfig, LlamaConfig, MambaConfig, Mamba2Config, MarianConfig, MBartConfig, MegaConfig, MegatronBertConfig, MistralConfig, MixtralConfig, MptConfig, MusicgenConfig, MusicgenMelodyConfig, MvpConfig, NemotronConfig, OlmoConfig, OpenLlamaConfig, OpenAIGPTConfig, OPTConfig, PegasusConfig, PersimmonConfig, PhiConfig, Phi3Config, PLBartConfig, ProphetNetConfig, QDQBertConfig, Qwen2Config, Qwen2MoeConfig, RecurrentGemmaConfig, ReformerConfig, RemBertConfig, RobertaConfig, RobertaPreLayerNormConfig, RoCBertConfig, RoFormerConfig, RwkvConfig, Speech2Text2Config, StableLmConfig, Starcoder2Config, TransfoXLConfig, TrOCRConfig, WhisperConfig, XGLMConfig, XLMConfig, XLMProphetNetConfig, XLMRobertaConfig, XLMRobertaXLConfig, XLNetConfig, XmodConfig.
```

### Your contribution

I'm happy to contribute.

Comments:
Hi @kingyiusuen, I think we could accept this PR! However, there are lots of modern models that will be much stronger at causal language modeling than DistilBert - out of curiosity, can I ask why you want to use DistilBert with a CLM head?
change apply_rotary_pos_emb of Glmmodel for GLM-Edge Series model
Author: zRzRzRzRzRzRzR
Pull request: yes

# What does this PR do?

This PR is to allow the new version of the GLM-4 model to use different rotary_pos_emb.
I am still researching how to modify modular_glm.py so that model_glm.py can automatically generate an additional parameter called apply_rotary_pos_emb.

## Who can review?

This PR may [Cyrilvallez](https://github.com/Cyrilvallez) to help.

Comments:
Now this implementation is compatible with both GLM-Edge and GLM-4 models, @Cyrilvallez , I would like to know how to modify modular_glm.py to achieve automatic updates, because some parts of the implementation in modeling_glm.py need to add new parameters to work properly.

I referred to your plan and modified it to look like this. I believe the mathematical logic of this implementation is equivalent.

I would like to know if there are any improvements needed for this version, and also, I would like to know if @Cyrilvallez could guide me on how to modify modular_glm.py to make good changes.
```
query_states, key_states = apply_rotary_pos_emb(
            query_states, key_states, cos, sin, partial_rotary_factor=self.partial_rotary_factor
        )
```

Let it automatically generate to modeling_glm.py.

cc @Cyrilvallez but I think it would help to remove unrelated changes! 🤗 

This modification should meet the requirements, and I have tried to remove all unnecessary code. The remaining code is all the code that will be used.

All good, merging!
Update the Python version in the Chinese README to match the English README. 
Author: vansin
Pull request: yes

Update the Python version in the Chinese README to match the English README. 


Comments:
cc @stevhliu!

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_34870). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
docs: HUGGINGFACE_HUB_CACHE -> HF_HUB_CACHE
Author: imba-tjd
Pull request: yes

- [x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).

see https://huggingface.co/docs/huggingface_hub/package_reference/environment_variables#deprecated-environment-variables


Comments:
cc @stevhliu 

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_34904). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
[`FlexAttention`] Update gemma2
Author: ArthurZucker
Pull request: yes

# What does this PR do?
There were small issues, mostly because we were missing transpose, thanks @vasqu. 
This was undetected because you don't get the version you requested, again caught by @vasqu, and wiill be fixed by #34896

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_34942). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix : Add PEFT from source to CI docker
Author: MekkCyber
Pull request: yes

# What does this PR do?
Install PEFT from source for the CI docker to avoid importing eetq as long as `shard_checkpoint` error is not solved : https://github.com/NetEase-FuXi/EETQ/issues/34

Here is the docker image with `peft` installed from source : https://github.com/huggingface/transformers/actions/runs/12047769639/job/33590976973

and Here is the github action before installing peft from source where we have an error related to `shard_checkpoint` : https://github.com/huggingface/transformers/actions/runs/12041342712/job/33573331770
## Who can review ?
@SunMarc 

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_34969). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

GPTQ tests use peft, and in the peft version installed in the docker, the `is_eetq_available` is not updated to handle the `shard_checkpoint` error yet that's why we need to install from source
Avoid calling `get_max_length`
Author: ydshieh
Pull request: yes

# What does this PR do?

Some tests are failing after #34247 as they are calling `get_max_length` which calls `logger`, and torch dynamo hate it with

> torch._dynamo.exc.Unsupported: Logger not supported for non-export cases

Let's just call `get_max_cache_shape` as `get_max_length` is just `logger + get_max_cache_shape`

`PaliGemmaForConditionalGenerationModelTest::test_generate_with_static_cache` and `tests/models/granite/test_modeling_granite.py::GraniteModelTest::test_generate_from_inputs_embeds_with_static_cache ` are passing now but 

> GraniteMoeModelTest::test_generate_from_inputs_embeds_with_static_cache

still has data dependent operation issue and failed. That should be addressed in a separate PR.



Comments:
> PaliGemmaForConditionalGenerationModelTest::test_generate_with_static_cache

Might be flaky (1 failed in 100 run in my last check). I will look at this but open another PR for it.

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_34971). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
mark `TFAutoModelTest::test_cached_model_has_minimum_calls_to_head` flaky
Author: ydshieh
Pull request: yes

# What does this PR do?

The TF version of 
> test_cached_model_has_minimum_calls_to_head
is flaky on daily CI (not on CircleCI).

The torch version of it seems fine.

I have hard time to reproduce it even with SSH into runner or even trigger 3 times with GitHub Actions workflow.
(Might happen only when the system is in a particular state)

Guess it's OK to mark it as flaky for now?

Comments:
OK, running 4 times with GA workflow I can get it shown.

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_34878). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
🌐 [i18n-KO] Translated encoder-decoder.md to Korean
Author: maximizemaxwell
Pull request: yes

# What does this PR do?

Translated the encoder-decoder.md file of the documentation to Korean.
Thank you in advance for your review.

Part of https://github.com/huggingface/transformers/issues/20179
## Before reviewing

  - [x]  Check for missing / redundant translations (번역 누락/중복 검사)
  - [x] Grammar Check (맞춤법 검사)
  - [x] Review or Add new terms to glossary (용어 확인 및 추가)
  - [x]  Check Inline TOC (e.g. [[lowercased-header]])
  - [ ]  Check live-preview for gotchas (live-preview로 정상작동 확인)

## Who can review? (Initial)

@junejae, @Jwaminju, @010kim, @4N3MONE, @boyunJang
## Before submitting

   - [x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
   - [x]  Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#start-contributing-pull-requests),
    Pull Request section?
   - [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
    to it if that's the case.
   - [x]  Did you make sure to update the documentation with your changes? Here are the
    [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
    [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
   - [ ]  Did you write any new necessary tests?

## Who can review? (Final)

@stevhliu May you please review this PR?

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_34880). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

몇 가지 제안사항 남겨두었습니다. 번역 고생하셨습니다!

Resolved!🤗
Add class properties with warnings
Author: amyeroberts
Pull request: yes

# What does this PR do?

Adds properties with deprecations warnings to image processors for backwards compatibility. This resolves issues users had when trying to reference a deprecated property e.g. `image_processor.reduce_labels`. 

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? 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](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?

Comments:
_The documentation is not available anymore as the PR was closed or merged._
PeftAdapterMixin.load_adapter takes the model out of eval()
Author: njbrake
Pull request: no
Labels: name: bug

name: PEFT

https://github.com/huggingface/transformers/blob/c2820c94916e34baf4486accae74760972183a2f/src/transformers/integrations/peft.py#L71

When you load a trained adapter using `load_adapter` it takes the model out of eval mode: I would expect this behavior from the `add_adapter` method, but not the loading method. 

```
model_dir = "/path/to/seq2seq/model"
tokenizer = AutoTokenizer.from_pretrained(model_dir)
model:PeftAdapterMixin = AutoModelForSeq2SeqLM.from_pretrained(model_dir).to(device)
model.eval()
for module in model.modules():
    assert module.training == False # This will not throw an exception
model.load_adapter(adapter_path)
for module in model.modules():
    assert module.training == False # This will throw an exception
```

Comments:
Not sure who to ping for PEFT in Transformers, so cc @sayakpaul @pacman100 @BenjaminBossan 

Thanks for reporting, I agree that it is not the desired behavior that the LoRA weights would be trainable after calling `model.load_adapter`. In fact, when using `PeftModel`, the LoRA weights are not trainable by default, so this behavior is also inconsistent.

@njbrake For now, you can manually call `model.eval()` after loading the adapter. I'll work on a PR to fix the behavior.

@Rocketknight1 Sourab (pacman) is no longer at HF, so no need to ping him :)

@njbrake Could you please check if `any(p.requires_grad for p in model.parameters())`? I think it should return `False`, which means we're basically good here.

Of course, it would still be better if we didn't have `module.training is True` for the LoRA modules, but since those are just linear layers, it doesn't change their behavior.

@BenjaminBossan thanks for the response, I'll check that!

I am pretty sure that this is an issue, because if I remember correctly, the LoRA module can have a dropout layer so this would have an effect on that. 

I was observing non-deterministic behavior when generating with beam search (which should be deterministic), until I re set the model.eval() after loading the adapters, so I don't think that everything is ok as-is. 

> I am pretty sure that this is an issue, because if I remember correctly, the LoRA module can have a dropout layer so this would have an effect on that.

Right, if dropout > 0, this is indeed an issue. I created a PR that should fix hat: #34509. Also, note that if you load the model via PEFT, you don't run into this issue:

```python
from peft import PeftModel
base_model = ...
peft_model = PeftModel.from_pretrained(base_model, <path-to-adapter>)
```


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](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md) are likely to be ignored.
[PEFT] Set eval mode when loading PEFT adapter
Author: BenjaminBossan
Pull request: yes

# What does this PR do?

When calling `model.load_adapter` to load a PEFT adapter, by default the adapter should be set to eval mode. This is now correctly done. Users can still pass `is_trainable=True` to load the adapter in training mode.

Fixes #34469


## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [x] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [x] Did you write any new necessary tests?

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_34509). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@ArthurZucker could you please review or suggest a reviewer?

Another ping @ArthurZucker for review or reviewer suggestion.

Thanks for the review @Rocketknight1.

Regarding your suggestion about inferring `is_trainable` from the model. This would only make a difference for the case where the user explicitly puts the model into training mode, right? However, this would be highly unusual, as with PEFT, you typically want the base weights to be frozen and only train the PEFT weights. Therefore, I don't think this would help in a real world use case. And for the rare occasion that the user wants all parameters to be trainable for whatever reason, they could just call `model.train()` after calling `load_adapter`.

This doesn't mean that your suggestion can't be implemented, it would just add a bit of complexity where it's probably not needed. LMK what you think.

Yeah, sorry, this is a good point - I forgot that in PEFT training the base model generally wouldn't be trainable. I think your approach in the PR is better!

Technically, this would be a breaking change, but I'd consider this more like a bugfix, so if users are relying on the old behavior, they're relying on buggy behavior. It's not quite as clear cut, but e.g. this PR aligns transformers with how PEFT behaves. Up to you if you consider this a breaking change or not.
Fixes bug in image_transforms.py
Author: AkshadShyam14
Pull request: yes
Labels: name: bug

name: Vision

name: Processing

# What does this PR do?

This PR aims to fix a [bug](https://github.com/huggingface/transformers/issues/34920) raised in the resize function in image_transforms.py

Fixes # (issue)
The function throws an error because PIL cannot accept an image if it has negative values. The image is normalized so that all values are in the range of [0,1].


## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? 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](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?




Comments:
Thanks for your comment @qubvel!. I'll try to find a different way.
🚨🚨🚨 Changed DINOv2Config default patch size to 14
Author: OFSkean
Pull request: yes
Labels: name: bug

# What does this PR do?
The DINOv2 model was trained and released with a patch size of 14. This PR changes the default in DINOv2Config from patchsize=16 to patchsize=14 to reflect that.

Fixes #34292


## Before submitting
- [x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [x] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?
@qubvel 


Comments:
DinoV2 is incorrectly documented as a default patch size of 16 instead of 14
Author: OFSkean
Pull request: no
Labels: name: bug

name: Vision

### System Info

transformers version 4.40.2, python version 3.10

### Who can help?

@amyeroberts @NielsRogge 

### Information

- [X] The official example scripts
- [ ] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

from transformers import AutoConfig
config = AutoConfig.from_pretrained("facebook/dinov2-base")
print(config.patch_size) # prints 14

### Expected behavior

The DinoV2 model was [trained](https://arxiv.org/pdf/2304.07193) with a patch size of 14 and [released](https://github.com/facebookresearch/dinov2) with that patch size on Github. Some time later, @NielsRogge [ported](https://github.com/facebookresearch/dinov2/issues/153) it into Huggingface. The config.jsons for the Dinov2 models ([base](https://huggingface.co/facebook/dinov2-base/blob/main/config.json), [large](https://huggingface.co/facebook/dinov2-large/blob/main/config.json)) correctly say patch size of 14, but the default for Dinov2Config is 16 ([docs](https://huggingface.co/docs/transformers/main/model_doc/dinov2#transformers.Dinov2Config), [code](https://github.com/huggingface/transformers/blob/53fad641cfdb5105e2470bcf3ef17ea8e25cc300/src/transformers/models/dinov2/configuration_dinov2.py#L121C9-L121C19)).

This error was a bit confusing for me at first as I was trying to hunt down why my sequence length was 257 instead of 197. It makes sense to correct the documentation to show 14 as the default.

Comments:
cc @qubvel as well

Hi @OFSkean! Thanks for submitting the issue!
Would you like to update dinov2 [configuration](https://github.com/huggingface/transformers/blob/main/src/transformers/models/dinov2/configuration_dinov2.py) to reflect the correct patch size?

Sure! I'll make a pull request for it shortly.

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](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md) are likely to be ignored.