noamaanMulla-03/transformers-issues huggingface dataset:
extend fp_quant cases to xpu
Author: yao-matrix
Pull request: yes

w/ FP-Quant PR https://github.com/IST-DASLab/FP-Quant/pull/11 merged, all pseudoquant cases pass with triton kernel on XPU. For next-gen XPU which support native mxfp4/nvfp4, will upstream once they are ready. @ydshieh, pls help review, thx very much.

Comments:
@SunMarc , could you pls take a look? Thx very much.

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

run-slow: fp_quant_integration

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

# What does this PR do?



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

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

run-slow: vit

run-slow: vit

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

models: ["models/vit"]
quantizations: []

## CI Results
[Workflow Run ⚙️](https://github.com/huggingface/transformers/actions/runs/19116448981)

### Model CI Report

#### ❌ Failed tests

- [vit](https://github.com/huggingface/transformers/actions/runs/19116448981/job/54713878805):
    tests/models/vit/test_modeling_vit.py::ViTModelTest::test_config
Fix inconsistency of commit sha during the workflow run
Author: ydshieh
Pull request: yes

# What does this PR do?

In `.github/workflows/check_failed_tests.yml`, we have (before this PR)

```
        uses: actions/github-script@v6
        with:
          script: |            
            const { data: pr } = await github.rest.pulls.get({
              owner: context.repo.owner,
              repo: context.repo.repo,
              pull_number: ${{ inputs.pr_number }}
            });

            const { data: merge_commit }  = await github.rest.repos.getCommit({
              owner: pr.base.repo.owner.login,
              repo: pr.base.repo.name,
              ref: pr.merge_commit_sha,
            });

            core.setOutput('merge_commit_base_sha', merge_commit.parents[0].sha);
```

We get the PR merge commit by fetching from github here. But if the `main` branch is updated during the workflow run, it may cause the situation where we use the old merge commit in an earlier job/step of the workflow run, but use the new merge commit here. 

We already had this happened and the job `check_failed_tests` fails, reporting no failure found for the PR.

This PR fixes this issue by using `${{ inputs.commit_sha }}` directly, which is the merge commit sha being passed if it is triggered from a PR. 

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42074). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Testing checkpoint limit changes from PR #37196
Author: Aravind-11
Pull request: yes

# What does this PR do?

This PR adds separate checkpoint limits for regular checkpoints and best model checkpoints in the Trainer.

## Changes:
- Adds `save_total_limit_best` parameter to `TrainingArguments` to control the number of best checkpoints kept
- Separates checkpoint management logic so that best model checkpoints and regular interval checkpoints are tracked independently
- Best checkpoints (based on metrics) are no longer deleted when regular checkpoints are rotated

## Motivation:
Currently, `save_total_limit` applies to ALL checkpoints, meaning best models can be deleted to make room for new regular checkpoints. This PR allows users to preserve their best-performing models while limiting regular checkpoint storage.

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).
- [x] Did you write any new necessary tests?


## Who can review?

@vasqu 

Comments:
hi @vasqu , would love your inputs on this. I'm not sure if my logic is right , are you willing to check it? Thanks a lot!

cc @SunMarc 

> cc @SunMarc

Hi @SunMarc ! Could you please review the code and let me know what you think? Thank you!
Fix logic in setting self.fsdp when it is False
Author: roychan
Pull request: yes

# What does this PR do?

This PR fixes the logic in setting `self.fsdp` in `_process_fsdp_args` in src/transformers/training_args.py. In the original logic, when `self.fsdp` is False, it will not be converted to list, and cause the later logic below failed because `self.fsdp` is a boolean (False).
```
FSDPOption.FULL_SHARD in self.fsdp and FSDPOption.SHARD_GRAD_OP in self.fsdp:
```

This diff fixes it by initializing it to list.

## Who can review?

@SunMarc 


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

> Thanks for spotting this ! In which cases fsdp is set to `False` automatically ? Maybe we can fix that also

Thank you for reviewing the change. It was set in my code base (outside transformers) and I have it fixed (set to None) already.
Remove 🚨 emojis and Windows/CI UTF-8 workaround instructions
Author: N-Yashwitha
Pull request: yes
Labels: name: Code agent slop

## Description:
This PR removes all 🚨 emojis from the codebase and documentation to ensure ASCII compatibility on Windows systems.
It also deletes obsolete Python UTF-8 I/O workaround instructions that were previously added for Windows/CI environments.

These changes prevent encoding issues when running scripts on Windows or CI pipelines, and clean up unnecessary documentation instructions.

## Changes include:

Removal of 🚨 emojis from code and docs.
Removal of Windows/CI Python UTF-8 workaround instructions from documentation.
Minor cleanup of related documentation sections.

## Checklist before submitting:
 - [ ] This PR fixes a cross-platform compatibility issue.
 - [ ] Documentation updated.
 - [ ] No new tests required as the change is non-functional.

## Issue reference:
Fixes cross-platform encoding issues caused by non-ASCII characters in the codebase.

Comments:
Can I know the reason that why my pr is not merged , as this is my first contribution in git .
4.1V Model and GLM-4.5V Model Conversion Code Updates
Author: zRzRzRzRzRzRzR
Pull request: yes

+ Fixed weight conversion issues for some model providers and removed some debug logs
+ Simplified some functions

Comments:
Hi, is there a reference somewhere for the issues this is fixing?

No, but I encountered some bugs when converting the open-source model at https://github.com/thu-coai/Glyph, so I fixed them here together.
The internal weights have not been publicly released and are only obtained by the official team and provider, so there won't be any issues for converting to code that supports the transformers library.

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

run-slow: glm4v, glm4v_moe

Thanks, lets merge!

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41784). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Add Pull Request (PR) Template
Author: dimpal-yadav
Pull request: no

Currently, the repository does not have a Pull Request (PR) template. This makes it harder for contributors to provide consistent information when opening PRs.

Proposed Solution:
Add a PR template file at .github/pull_request_template.md.

The template should include:
Description of changes
Related issues (Fixes #issue)
Screenshots (if applicable)
Type of change (Bug fix, Feature, Enhancement, Documentation)
Checklist (self-review, code style, documentation update)

Benefits:
Ensures all PRs have consistent structure.
Helps maintainers review PRs faster.
Improves contributor experience and professionalism of the project.

Comments:
Hey @dimpal-yadav I am looking forward to working on this issue. Could you please assign it to me?


Hi! @dimpal-yadav 👋

I checked the repository and noticed that `PULL_REQUEST_TEMPLATE.md` already exists in the `.github` folder. It seems like the PR template is already implemented. Please let me know if any updates or improvements are needed.

Thanks!


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.
Mbart decoder ignoring index 0 from labels | index 1 from dec in
Author: jaaabir
Pull request: no
Labels: name: bug

### System Info

I am creating a ocr model using VisionEncoderDecoderModel class by connecting plm vision tower and donut base decoder (mbart model). 

I am using teacher forcing method to train the model ( default training  and i found out that the model is ignoring index 0 from the target ( index 1 from the decoder_input_ids ). 

I read the documentation for mbart and it says lang_code should be the bos for the target labels. but unlike the traditional methods where mbart used for translation task im using it for image - text task. 

and when i use the Seq2SeqTrainer to train the model i notice that the model is skipping is index 0 no matter what token is present there. 

I made my trainer to print the labels, dec in ( my own shift right just to display ) and pred. this is how it looks: 

```python
label: [985, 735, 8, 690, 28264, 1448, 15320, 8, 4467, 18823, 258, 30606, 5965, 2164, 451, 8, 4467, 18823, 35, 2, -100, -100, -100, -100, -100, -100, -100, -100, -100]
decin: [2, 985, 735, 8, 690, 28264, 1448, 15320, 8, 4467, 18823, 258, 30606, 5965, 2164, 451, 8, 4467, 18823, 35, 2, 1, 1, 1, 1, 1, 1, 1, 1]
preds: [735, 8, 690, 28264, 1448, 15320, 8, 4467, 18823, 258, 30606, 5965, 2164, 451, 8, 4467, 18823, 35, 2, 4467, 2, 2, 2, 185, 2, 2, 2, 2]


label: [15418, 417, 893, 7271, 12, 8, 6583, 13, 46, 6549, 5538, 3632, 388, 8, 3633, 11, 34, 5221, 8, 188, 28, 2234, 8, 22, 11, 8, 26, 8340, 2]
decin: [2, 15418, 417, 893, 7271, 12, 8, 6583, 13, 46, 6549, 5538, 3632, 388, 8, 3633, 11, 34, 5221, 8, 188, 28, 2234, 8, 22, 11, 8, 26, 8340]
preds: [417, 893, 7271, 12, 8, 6583, 13, 46, 6549, 5538, 3632, 388, 8, 3633, 11, 34, 5221, 8, 188, 28, 2234, 8, 22, 11, 8, 26, 8340, 2]


label: [877, 8, 13, 397, 8, 3038, 10180, 7049, 88, 8, 13, 5348, 9, 36, 208, 123, 11, 12311, 148, 2696, 2, -100, -100, -100, -100, -100, -100, -100, -100]
decin: [2, 877, 8, 13, 397, 8, 3038, 10180, 7049, 88, 8, 13, 5348, 9, 36, 208, 123, 11, 12311, 148, 2696, 2, 1, 1, 1, 1, 1, 1, 1]
preds: [8, 13, 397, 8, 3038, 10180, 7049, 88, 8, 13, 5348, 9, 36, 208, 123, 11, 12311, 148, 2696, 2, 2, 2, 2, 2, 2, 2696, 2, 2]
```

lets assume that the language code is 0, and thats in the beginning, that will be ignored too. how do i make the model to not ignore the index 0 from the labels? 





### Who can help?

@ArthurZucker 
@Cyrilvallez 
@yonigozlan 
@molbap 
@zucchini-nlp 
@itazap 

### Information

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

### Tasks

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

### Reproduction

https://colab.research.google.com/drive/1nLCDlFyKhqCGu7dhlxJ0JiCRYjG24vbO?usp=sharing

### Expected behavior

I would like the decoder model to not ignore the index 0 from the labels. so that it will be 

<img width="182" height="136" alt="Image" src="https://github.com/user-attachments/assets/18a8e465-c235-4ac5-a9e2-f13d41bec964" />

  

Comments:
This is more of a request for technical assistance than a bug in transformers!
feat(ci): add continuous batching to benchmarks
Author: McPatate
Pull request: yes
Labels: name: run-benchmark


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

@copilot, in the `Self-hosted runner (benchmark)` I have an odd `TypeError("ContinuousBatchingManager.add_requests() got an unexpected keyword argument 'streaming'")`. The change is indeed reflected in the PR's diff and it works locally. Could you fix the issue? It's causing a downstream OOM due to improper shutdown and freeing of the `ContinuousBatchingManager` instance. Feel free to tackle that issue as well.

@McPatate I've opened a new pull request, #42063, to work on those changes. Once the pull request is ready, I'll request review from you.

@copilot in the `Self-hosted runner (benchmark)` the run benchmarks step completes without finishing and it is marked as successful. could you investigate and fix?

@McPatate I've opened a new pull request, #42067, to work on those changes. Once the pull request is ready, I'll request review from you.

@copilot removing the `finally` was indeed a mistake but that is not the issue at hand. I've fixed this issue, but the problem mentioned here:
> https://gh.io/copilot-coding-agent-docs in the Self-hosted runner (benchmark) the run benchmarks step completes without finishing and it is marked as successful. could you investigate and fix?

happens on main also. Can you take a look again?

@McPatate I've opened a new pull request, #42068, to work on those changes. Once the pull request is ready, I'll request review from you.
Variable name mismatch on `MixtralExperts.forward()`
Author: kwonmha
Pull request: no
Labels: name: bug

### System Info

latest(current) transformers on github

### Who can help?

_No response_

### 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

https://github.com/huggingface/transformers/blame/b9f90dc388fd415a2ba2a6a31a372f451d4a4eed/src/transformers/models/mixtral/modular_mixtral.py#L164-L171
`top_k_index`, `top_k_weights` are used on function definition, `selected_experts `, `routing_weights ` are used on function docstring.


### Expected behavior

It would be better if their name match.

It may be a minor issue but it is having impact on every other models inherits this code block.
@ArthurZucker

Comments:
Hi @kwonmha! I'd like to work on fixing this inconsistency.

I can update the docstring to use `top_k_index` and `top_k_weights` instead of `selected_experts` and `routing_weights` to match the actual parameter names.

Should I go ahead with this fix? Are there any models that need the same update?

We're happy to accept a PR for this!

Hi @kwonmha I am also trying to solve this, will that be fine?

Hi all.
I don't mind, anyone can fix this.
It looks like relevant PR is already created. 😮

Feel free to close this issue whenever proper PR gets merged.

hello @Rocketknight1 the PR I sent looks good in formatting but check_modular_conversion.py keeps failing while trying to edit all MoE docstrings, I don't know why

Hi @diegoakel, after making `modular` changes, run `make fix-copies`. `modular` files are like 'blueprints' for the actual `modeling` files, and running `make fix-copies` propagates the changes appropriately.

Thanks! @Rocketknight1. Now the tests pass correctly. It did change 16 other modeling files, which to my understanding are others that were not updated on a previous change of their respective modular files?

Hi @diegoakel, yes! All those other models were inheriting from `Mixtral`, and their docstrings were also incorrect as a result. Your PR looks correct, I'll merge it now.
Fix modular docstring for Mixtral
Author: diegoakel
Pull request: yes

# What does this PR do?

This PR is a very small change for the docstring of all MoE modular/modulling files where there was a mismatch between  top_k_index, top_k_weights are used on function definition, selected_experts , routing_weights  are used on function docstring.

Fixes #41984


## 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.
- [ ] 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?

@Rocketknight1 



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

run-slow: deepseek_v2, deepseek_v3, dots1, flex_olmo, glm4_moe, glm4v_moe, hunyuan_v1_moe, jamba, lfm2_moe, minimax, mixtral, olmoe, phimoe, qwen2_moe, qwen3_moe, qwen3_next

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42041). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix qwen3 vl docstring
Author: Arcanixhades0
Pull request: yes

# What does this PR do?

This PR fixes a typo in the docstring of the `apply_interleaved_mrope` function within `Qwen3VLTextRotaryEmbedding`. The example of the interleaved frequency layout was incorrectly stated as `[THTHWHTHW...TT]` and has been corrected to `[THWTHWTHW...TT]` to accurately reflect the reorganization.

Fixes #42084


## 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?
- [ ] 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?


## Who can review?

@zucchini-nlp


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

run-slow: qwen3_vl
Reinstate self.scaling in Gemma3nTextAttention
Author: RyanMullins
Pull request: yes

# What does this PR do?

Previously, the `Gemma3nTextAttention` class removed the `self.scaling` property and passed 1.0 as a hard-coded value to the `attention_interface()` function. 

This PR reinstates the `self.scaling` property, sets it to 1.0, and passes `self.scaling` to the `attention_interface()` function  in `Gemma3nTextAttention.forward()`, which should make it more configurable for users interested in experimenting with the Gemma 3n arch, and improves the lineage of its modular inheritance relative to Gemma 3.

## 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?


## Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

@ArthurZucker @Cyrilvallez


Comments:
Seems like a core question for text model philosophy so cc @arthurzucker!

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

run-slow: gemma3n
i want to request a demo code for StatefulDataLoader , i want to use data checkpoint to recover the train stage`s data state, not only model state , how to use ,StatefulDataLoader or some code to reach it ?
Author: ldh127
Pull request: no
Labels: name: bug

i want to request a demo code for StatefulDataLoader , i want to use data checkpoint to recover the train stage`s data state, not only model state , how to use ,StatefulDataLoader or some code to reach it ?

recover data state ,not only model state , i wish i said my request clearly .
how to use accelerate + transformers trainer to train model ,when training is broken ,it can recover from data checkpoint and model checkpoint ? thanks

i wish you understand what i said

Comments:
cc @sunmarc maybe, do we have any example code to load dataloader and model state together?

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.