noamaanMulla-03/transformers-issues huggingface dataset:
Share embedding modules in BART, not only weights
Author: githubnemo
Pull request: yes

Embedding modules are now shared between encoder, decoder and shared - it is the same module, like in the T5 implementation.

This has the benefit that it does not matter which module is returned in `get_input_embeddings`, the caller of the latter can be sure that modifications done to that (e.g., hooks) apply to the embeddings.

Background: While revamping the gradient checkpointing tests in PEFT via peft#2860 we found that the gradient enable step
(`modeling_utils.enable_input_require_grads`) does not work for BART. This leads to gradient checkpointing with `use_reentrant=True` to fail as it will not detect any gradients. The reason for this is that the returned value by `get_input_embeddings` (`self.shared`) is not the module that is called in the encoder, therefore any hooks added to `self.shared` are not run - in this case the hook set by `enable_input_require_grads`.

Since the background is a missing hook I've added a test that tests directly the ability to define hooks and their ability to being called.

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

run-slow: bart

This comment contains run-slow, running the specified jobs: 

models: ['models/bart']
quantizations: [] ...

Checked in #41828 for the multi gpu tests that failed, seems like even without changes it fails in the runners...

Edit: seems like a general issue, talked internally in slack so nothing to do on your side

**[For maintainers]** Suggested jobs to run (before merge)

run-slow: bart, plbart
CLIP incompatible with Flash Attention 3
Author: akashpalla
Pull request: no
Labels: name: bug

### System Info

- `transformers` version: 4.57.0
- Platform: Linux-6.14.0-33-generic-x86_64-with-glibc2.39
- Python version: 3.12.3
- Huggingface_hub version: 1.0.0.rc4

### Who can help?

@ArthurZucker @Cyrilvallez

### Information

- [ ] 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 diffusers import EulerDiscreteScheduler, StableDiffusionXLPipeline
import torch
import os

model_path =os.getenv('MODEL_PATH')
print(model_path)
pipe = StableDiffusionXLPipeline.from_pretrained(
    model_path,
    variant="fp16",
    torch_dtype=torch.float16
).to("cuda")
pipe.fuse_qkv_projections()

pipe.text_encoder.config._attn_implementation = "flash_attention_3"
pipe.text_encoder_2.config._attn_implementation = "flash_attention_3"

prompt = ["A city at night with people walking around."] * 8
image = pipe(prompt, num_inference_steps=1).images[0]
```

Input into `_upad_input`
```
Starting with query_length: 77
query_layer shape: torch.Size([8, 77, 12, 64])
key_layer shape: torch.Size([8, 77, 12, 64])
value_layer shape: torch.Size([8, 77, 12, 64])
attention_mask shape: torch.Size([8, 1, 77, 77])
```

output from `_upad_input`

```
q shape: torch.Size([23408, 12, 64])
k shape: torch.Size([23408, 12, 64])
v shape: torch.Size([23408, 12, 64])
cu_seq_lens_q: torch.Size([8, 1, 78])
cu_seq_lens_k: torch.Size([8, 1, 78])
max_length_q: 0
max_length_k: 0

```


### Expected behavior

I'm trying to enable Flash Attention 3 for the CLIP encoder in SDXL. 

Is the line in the forward pass supposed to include FA3 as well?

https://github.com/huggingface/transformers/blob/19df66dcba7690fab0b82105c154685c63016a21/src/transformers/models/clip/modeling_clip.py#L322

Currently when the attention_implementation is set to FlashAttention3 the attention_mask is set to the the causal_attention_mask which is 4D and when passed into [_upad_input](https://github.com/huggingface/transformers/blob/19df66dcba7690fab0b82105c154685c63016a21/src/transformers/modeling_flash_attention_utils.py#L237) which only supports a 2D attention_mask leads to garbage output https://github.com/huggingface/transformers/blob/19df66dcba7690fab0b82105c154685c63016a21/src/transformers/modeling_flash_attention_utils.py#L258 



Comments:
Hey @akashpalla,
yea CLIP is already quite old so it's easy to miss these. Any checks on flash attn like `self.config._attn_implementation == "flash_attention_2"` should be changed to `"flash" in self.config._attn_implementation` instead. That would also include kernels flash attn to work.

Do you mind opening a PR to fix this 🤗 

Hi, can I work on this issue?

@Aravind-11 sorry, there already is a PR open for this. In the future, you don't really have to ask for permission and can open a PR; just make sure that it's coordinated, i.e. no other similar PRs are already open
:rotating_light: [`Clip`] Fix masking and enable flash attention on all model types
Author: vasqu
Pull request: yes
Labels: name: Vision

Clip used old mask APIs leading to a confused usage:
- A causal mask (normal triu mask)
- A padding mask (encoder mask == only accounting for padding)
- Add both of above == final mask --> causal mask with padding

^ works only for interfaces with support for 4D masks which disabled FA usage in general.

This PR now correctly changes this to the new API which handles padding automatically. We have to additionally pass the `is_causal` kwarg to dynamically switch between modality types (text == causal, image == full). This is only enabled through recent PRs (fa #39707, sdpa #41692).

Closes #41673
Fixes #41668

Comments:
cc @yonigozlan when you come across models like these in the vision refactors

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

run-slow: clip

This comment contains run-slow, running the specified jobs: 

models: ['models/clip']
quantizations: [] ...

@molbap @zucchini-nlp I changed a few things to align the kwargs with our modern practices, i.e. see 764e63fa819d02d4e570e2529a36fd0050121114

This makes kwarg easy to type properly, otherwise we probably need to type it as FA kwargs :thinking: 

CI has issues today, will probably check tomorrow again (and propogate the changes to metaclip 2 + mlcd) and merge then

run-slow: clip, metaclip_2, mlcd, llava

This comment contains run-slow, running the specified jobs: 

models: ['models/clip', 'models/llava', 'models/metaclip_2', 'models/mlcd']
quantizations: [] ...

run-slow: clip, metaclip_2, mlcd, llava

This comment contains run-slow, running the specified jobs: 

models: ['models/clip', 'models/llava', 'models/metaclip_2', 'models/mlcd']
quantizations: [] ...

Yea, the CI is not having a good day :D locally all the relevant tests passed, especially the integration tests - checking tomorrow

run-slow: clip, metaclip_2, mlcd, llava

This comment contains run-slow, running the specified jobs: 

models: ['models/clip', 'models/llava', 'models/metaclip_2', 'models/mlcd']
quantizations: [] ...

run-slow: clip, metaclip_2, mlcd, llava

This comment contains run-slow, running the specified jobs: 

models: ['models/clip', 'models/llava', 'models/metaclip_2', 'models/mlcd']
quantizations: [] ...

**[For maintainers]** Suggested jobs to run (before merge)

run-slow: clip, metaclip_2, mlcd

run-slow: clip, metaclip_2, mlcd, llava

This comment contains run-slow, running the specified jobs: 

models: ['models/clip', 'models/llava', 'models/metaclip_2', 'models/mlcd']
quantizations: [] ...
Checkpoints copy
Author: Aravind-11
Pull request: yes

# What does this PR do?

Fixes #37196


## Before submitting

- [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?


## Who can review?



Comments:
copy of #37196 to check failing tests
Author: Aravind-11
Pull request: yes

# What does this PR do?

This pr is just a copy of the previous pr. Further tests and fixes are needed. 

Fixes  #37196 


## Before submitting
- [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?


## Who can review?




Comments:
Added separate limits for saving full checkpoints and model weights
Author: GitGautamHub
Pull request: yes

What does this PR do?
This PR introduces separate limits for saving full checkpoints and model weights in the Trainer class. Currently, save_total_limit applies to both, which can lead to inefficient storage management. This change allows users to:

Retain intermediate model weights for analysis without storing full checkpoints unnecessarily.

Ensure that the latest full checkpoint is available for resuming training.

Fixes Issue
Fixes #37195 

Motivation
The current implementation of save_total_limit does not differentiate between full checkpoints and model weights. This can be problematic when users require frequent weight saves but only need a limited number of full checkpoints. Introducing separate limits enhances flexibility and optimizes storage usage.

Changes Made
Updated _rotate_checkpoints() in trainer.py to support independent limits for full checkpoints and model weights.

Introduced save_checkpoint_limit and save_model_weights_limit as configurable parameters.

Updated relevant documentation and method docstrings.

Tests
Due to local environment issues, I was unable to run the tests locally.

The CI/CD pipeline should validate the changes.


Comments:
Hi 👋, thank you for opening this pull request! The pull request is converted to draft by default. The CI will be paused while the PR is in draft mode. When it is ready for review, please click the `Ready for review` button (at the bottom of the PR page). This will assign reviewers and trigger CI.

cc @muellerzr @sunmarc here and to the original issue #37195

Hi @GitGautamHub , what's the status on this? I can take this up but it looks very complicated since these changes could affect a lot of other files. I don't know if i'm right. Would like your inputs on this.
[`Gemma3n`] Fix regression in test
Author: vasqu
Pull request: yes

Draft for now checking things

Comments:
run-slow: gemma3n

**[For maintainers]** Suggested jobs to run (before merge)

run-slow: gemma3n

This comment contains run-slow, running the specified jobs: 

models: ['models/gemma3n']
quantizations: [] ...

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

Other langs docs are failing on main. This looked like the root cause

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41791). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix TypeError: find_adapter_config_file() got an unexpected keyword argument '_adapter_model_path'
Author: albertvillanova
Pull request: yes

Fix TypeError: find_adapter_config_file() got an unexpected keyword argument '_adapter_model_path'
- Pass original dict instead of copy to `maybe_load_adapters`

The `adapter_kwargs` is passed to `maybe_load_adapters` as unpacked keyword arguments: Python does not pass the original dictionary, but instead creates a new dictionary inside the function; so the `pop` inside the function does not have the intended behavior.
https://github.com/huggingface/transformers/blob/5db730786d87bde8397a207bd84ae0014054fc37/src/transformers/modeling_utils.py#L4383-L4387
```python
def maybe_load_adapters(
    pretrained_model_name_or_path,
    download_kwargs: DownloadKwargs,
    **adapter_kwargs,
):
    ...
    _adapter_model_path = adapter_kwargs.pop("_adapter_model_path", None)
```

This issue was introduced by PR:
- #41445

Related downstream issue:
- https://github.com/huggingface/trl/issues/4273

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

CC: @ArthurZucker (who opened the PR), @Cyrilvallez (who reviewed it).

I encountered this error in the PEFT CI, not sure if we need a separate test for this in transformers. Here is a minimal reproducer:

```python
from transformers import AutoModelForCausalLM
model_id = "peft-internal-testing/opt-125m-dummy-lora"
AutoModelForCausalLM.from_pretrained(model_id)
```

I can confirm that this PR fixes the issue, but relying on the side effect of calling `.pop` on the original dict is maybe not the best solution IMO.

Let me know if you would prefer that `maybe_load_adapters` returns a cleaned version of `adapter_kwargs`, besides current return values.

> Let me know if you would prefer that `maybe_load_adapters` returns a cleaned version of `adapter_kwargs`, besides current return values.

I think that's the cleaner solution but I'll leave the final decision to you / @ArthurZucker.

@ArthurZucker is it OK if I merge this PR as it is? Or should I wait for a transformers maintainer to merge it?
Thanks! :hugs: 

I'm also encountering this issue in my latest `sentence-transformers` tests, and I can confirm that this PR resolves the issue.

- Tom Aarsen

@albertvillanova I did approve the PR to make sure you merge it as its important :) 

Thanks @ArthurZucker , I was not sure about the merging policy in transformers. I know now! 🤗
[Trainer] accelerate contextparallel support in trainer
Author: kashif
Pull request: yes

# What does this PR do?

Add support for context parallel in the Trainer

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

~~Current status is a bit funky, the loss logging seems to be very weird, with outputs being correct, but logged losses being off sometimes:~~
<img width="1686" height="1035" alt="image" src="https://github.com/user-attachments/assets/5c2cd5d3-d4cc-4603-93dd-92bc75e82a7d" />


@SunMarc  I have fixed the issues you raised

Failing tests seem unrelated.

on it @SunMarc 

Am I missing something or was this feature merged w/o adding any tests?

I'm working on an HF Trainer integration PR for ALST/UlyssesSP via https://github.com/huggingface/accelerate/pull/3817 and I was hoping to have some existing CP tests I could extend/copy but I can't find any.

How will you know if this feature breaks if you have no tests? The Accelerate side doesn't test most of this feature either. I'm puzzled.

CI test PR https://github.com/huggingface/transformers/pull/41860
Variety of models not working sufficiently good on tool calling as has been advertised
Author: dvn8weil
Pull request: no
Labels: name: bug

### System Info

- `transformers` version: 4.53.3
- Platform: Linux-6.14.0-1014-gcp-x86_64-with-glibc2.39
- Python version: 3.12.3
- Huggingface_hub version: 0.34.4
- Safetensors version: 0.6.2
- Accelerate version: not installed
- Accelerate config: not found
- DeepSpeed version: not installed
- PyTorch version (accelerator?): 2.7.1+cu126 (CUDA)
- Tensorflow version (GPU?): not installed (NA)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed
- JaxLib version: not installed
- Using distributed or parallel set-up in script?: No
- Using GPU in script?: No
- GPU type: NVIDIA L4

### Who can help?

I have been trying out various small/medium size models for my tool calling usecase. 

The models i tried out are : 
- mistralai/Mistral-7B-Instruct-v0.3 
- ibm-granite/granite-20b-functioncalling
- Team-ACE/ToolACE-2-Llama-3.1-8B
- HuggingFaceTB/SmolLM3-3B

I tried out these because these have been said to perform very good for tool calling capability/use-case but neither of these have worked good enough (with my setup) for my use-case which is consistent function calling , with `"tool_choice": "auto"`. On the other hand, Qwen3-12B has been working very well for me , w.r.t.  tool calling capabilities. 

### Information

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

I am using vLLM to run the models.
Steps to reproduce the issues : 

- mistralai/Mistral-7B-Instruct-v0.3 : https://github.com/huggingface/transformers/issues/39852
- ibm-granite/granite-20b-functioncalling : https://github.com/huggingface/transformers/issues/40785
- HuggingFaceTB/SmolLM3-3B : https://github.com/huggingface/transformers/issues/40957

### Expected behavior

I am trying to understand if i have been setting up the models in an incorrect way. If someone can help me with understanding this, it will be really great.

Comments:
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.
Docs (zh-hans): Revert certain terms to English for clarity and professional consistency
Author: Ri-Nai
Pull request: no

Hello Hugging Face Team,

First of all, thank you for the great work on the `transformers` library and for providing multi-language documentation.

I am writing to suggest some improvements for the Simplified Chinese README file (`i18n/README_zh-hans.md`). As a Chinese-speaking user, I believe that reverting a few specific translated terms back to their original English form would significantly improve the document's professionalism and readability for the target audience (Chinese developers).

**The Core Problem:**

Certain terms are either translated into an overly informal nickname or into a Chinese phrase that is less common in a technical context than the English original. This can lead to ambiguity and a less professional tone.

**Specific Suggestions:**

I propose the following changes:

| Current Translation (原文) | Suggested Change (建议修改为) | Justification (理由) |
| :--- | :--- | :--- |
| `抱抱脸` | `Hugging Face` | While "抱抱脸" is a cute and friendly nickname, Chinese developers almost exclusively refer to the company and project as "Hugging Face". Using the official English name in technical documentation is more professional and aligns with community usage. |
| `流水线` (or other translations) | `pipeline` | The term `pipeline` is a core concept in the library. Chinese developers are very familiar with the English term. Translating it to "流水线" (assembly line) can sometimes be awkward or less precise than simply using the original term `pipeline`, which is common practice for key technical terms in Chinese documentation. |

**Why this is an improvement:**

1.  **Clarity:** Using the original English for core concepts and names avoids any potential translation ambiguity.
2.  **Professionalism:** It aligns the documentation with how these terms are actually used in technical discussions, tutorials, and code within the Chinese developer community.
3.  **Consistency:** It maintains consistency with the code itself, where developers will encounter `pipeline`, not `流水线`.

I would be happy to open a Pull Request to apply these changes if this proposal is accepted.

Thank you for your consideration

Comments:
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.
[CPU Safety] Automatically handle unsafe dtypes on CPU in from_pretrained() (#41867)
Author: ParthSharma272
Pull request: yes

# What does this PR do?

This PR adds **CPU dtype safety heuristics** to the model loading flow (`PreTrainedModel.from_pretrained`) to prevent potential slowdowns or errors when models are inadvertently loaded in `torch.float16` or `torch.bfloat16` on CPU.

It introduces a utility `apply_cpu_safety_settings()` in `transformers/utils/cpu_heuristics.py`, which:
- Detects unsafe dtypes (`float16` / `bfloat16`) on CPU.
- Applies a policy based on the `HF_CPU_DTYPE_POLICY` environment variable:
  - `"warn"` → logs a warning.
  - `"auto"` → converts model to `float32`.
  - `"error"` → raises `RuntimeError`.
  - Default (`warn_and_fallback`) → warns and safely converts to `float32`.

The heuristic is automatically called at the end of `from_pretrained()` to make model loading safer for CPU users.

Fixes #41868


### Motivation and context
Some users loading models on CPU encounter performance issues or silent errors when using `float16` / `bfloat16` tensors (which are unsafe for CPU inference).  
This PR adds a lightweight, configurable safeguard that prevents these cases without affecting GPU or quantized models.

### Changes introduced
- **New file**: `src/transformers/utils/cpu_heuristics.py`
- **Modified**: `modeling_utils.py` → integrates the safety call into `from_pretrained()`
- **New tests**: `tests/test_cpu_heuristics_patch.py` to verify warning, fallback, and error policies.

### Dependencies
None.

### Testing
All tests pass locally:
```bash
pytest tests/test_cpu_heuristics_patch.py -v



Comments: