noamaanMulla-03/transformers-issues huggingface dataset:
delete some tokenizer tests using pickle
Author: ydshieh
Pull request: yes

# What does this PR do?

There is no room for `pickle` within `transformers`!

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

Hi @itazap Ready for review 🙏 



I forgot the `pickle.loads` one, and pushed a new commit to remove them

https://github.com/huggingface/transformers/pull/41514/commits/f4a6bb52436cb931a9ac12ca634d137d582a7d97


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

run-slow: bert_japanese, code_llama, gemma, llama, moshi, pop2piano, seamless_m4t, siglip, speecht5, xglm, xlm_roberta
Jitter noise PR
Author: sambhavnoobcoder
Pull request: yes

## Issue Description

This pull request addresses a bug in the Switch Transformers architecture where the jitter noise (intended to be applied only for routing decisions) was also being unintentionally applied to the expert inputs.

Fixes : #33969 

## Problem Statement

In Switch Transformers, a small amount of jitter noise is added to the inputs at routing time to ensure route diversity. However, these jittered inputs were incorrectly passed along to the experts, which contradicts the original paper’s design and led to unexpected discrepancies in outputs.

## Root Cause

It was discovered that the code used the same hidden states for both routing and expert processing. When jitter noise was enabled in training mode, it directly modified these states in place, causing the experts to receive noisy inputs.

## Implementation

1. We now clone the original hidden states before applying jitter noise.  
2. A separate copy is used exclusively for computing router logits and probabilities.  
3. The unchanged hidden states are then fed to the experts to maintain the original semantics.

## Screenshot

<img width="1293" alt="Screenshot 2025-01-23 at 1 14 26 AM" src="https://github.com/user-attachments/assets/2d46438d-6344-4994-aa18-1e14376597e7" />

## Test Cases

1. **test_router_training_mode**  
   • Objective: Ensures that jitter noise is only applied during training.  
   • Checks that outputs differ between consecutive runs (due to noise) but original inputs remain unchanged.

2. **test_router_jitter_noise_separation **  
   • Objective: Verifies that jitter noise affects only the router’s internal computations and not the expert inputs.  
   • Confirms the logits differ when jitter is applied, while the main input stays the same.

3. **test_expert_inputs_consistency**  
   • Objective: Asserts that all expert inputs remain consistent, even when jitter is applied during training.  
   • Uses a forward hook on the first expert to capture its inputs across multiple runs and compares them.

With these changes and test additions, we ensure that Switch Transformers adhere to the original design while preserving backward compatibility and correctness.

**cc :** @ArthurZucker 

original pr refrence : #35847 

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

run-slow: switch_transformers

@ArthurZucker can you please have a look at this ? this a copy of an already pre approved branch https://github.com/huggingface/transformers/pull/35847 , looking to get this merged .
[VisionEncoderDecoderModel] Update loss function
Author: NielsRogge
Pull request: yes

# What does this PR do?

Models like Donut are currently broken on main, they can't be fine-tuned. In order to unblock users at #39473, this PR reverts #36753.

It looks like the `ForCausalLMLoss` class shifts the labels, however the VisionEncoderDecoderModel class does not expect shifted labels as seen [here](https://github.com/huggingface/transformers/blob/d42e96a2a731c4a772e396baa0d915524c873ff0/src/transformers/models/vision_encoder_decoder/modeling_vision_encoder_decoder.py#L547).

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40863). 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: vision_encoder_decoder

cc @ArthurZucker this one can be merged
Pop catch kwarg in run_hp_search_optuna() for flexible Optuna error handling
Author: nicha-api
Pull request: no
Labels: name: Feature request

### Feature request

Allow `catch` kwarg passthrough in `Trainer.hyperparameter_search(backend="optuna")` in order to expose Optuna’s `Study.optimize(..., catch=...)` argument by popping out catch kwargs before calling Optuna's `study.optimize()`.

### Motivation

The current Hugging Face Transformers integration with Optuna does not expose Optuna’s Study.optimize(..., catch=...) argument.
As a result, when a trial raises an exception (e.g., CUDA OOM, data mismatch, tokenizer failure), the entire hyperparameter search stops prematurely instead of marking the trial as failed or pruned.

Adding support for a catch parameter—forwarded to Optuna’s backend—would allow users to continue tuning even when individual trials encounter errors.

### Your contribution

[PR#41496](https://github.com/huggingface/transformers/pull/41496)

Comments:
cc: @Rocketknight1 

cc @sunmarc for Trainer

Hey @nicha-api, feel free to open the PR on transformers ! Happy to have this 

fixed
Fix pil dependency torch extra
Author: notkisk
Pull request: yes

## What does this PR do?

Fixes [[#39779](https://github.com/huggingface/transformers/issues/39779)]:
`ModuleNotFoundError: No module named 'PIL'` when running `transformers env` (or any CLI command) after installing `transformers[torch]` in a fresh environment.

---

## Problem

This error occurs because:

1. The `torch` extra in `setup.py` only includes `torch` and `accelerate`.
2. CLI commands eventually import `PIL` through the following chain:
   `transformers_cli.py → chat.py → serving.py → from PIL import Image`
3. `Pillow` is only included in the `vision` extra, not in the `torch` extra.

**Reproduction steps:**

```bash
docker run --rm -it python:3.13-slim-bookworm bash -c "python3 -m pip install transformers[torch]; transformers env"
```

---

## Solution

Added `Pillow` to the `torch` extra in `setup.py`:

<details>
<summary>Diff</summary>

```python
# Before
extras["torch"] = deps_list("torch", "accelerate")

# After
extras["torch"] = deps_list("torch", "accelerate", "Pillow")
```

</details>

This ensures that users who install with `pip install transformers[torch]` get a fully functional CLI environment without encountering missing dependencies.

---

## Testing

* ✅ Reproduced the original error in a fresh install
* ✅ Verified fix: `pip install transformers[torch]` now includes Pillow
* ✅ Confirmed `transformers env` works without errors
* ✅ No breaking changes to existing functionality

---

## Checklist (Before submitting)

* [x] Fixes a packaging bug (dependency)
* [x] Read the [[Pull Request section of the contributing guide](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request)](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request)
* [x] Linked to related issue: [[#39779](https://github.com/huggingface/transformers/issues/39779)](https://github.com/huggingface/transformers/issues/39779)
* [x] No documentation updates needed
* [x] No new tests needed (existing coverage is sufficient)

---

## Who can review?

@ArthurZucker @SunMarc – This is a small but important fix to the `torch` extra dependencies that prevents CLI errors in fresh installs.


Comments:
cc @gante since I think you worked on the chat update too!

Hi @notkisk 👋 Thank you for opening the PR, but there were actually a few more issues :o 

I've opened #39825 with a complete fix!
Revert some breaking changes bnb
Author: SunMarc
Pull request: yes

# What does this PR do?

This PR fixes issues related to bnb during a recent refactor. I didn't push some modifications 

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41581). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
NameError: name 'PreTrainedModel' is not defined
Author: deepNoah
Pull request: no
Labels: name: bug

### System Info
- ubuntu22.04 docker image.
- python3.10
- torch2.7.0-cu128
-  transformers-5.0.0.dev0

---
I was able to load the model fine until yesterday, but suddenly it stopped working with the error below.
> <img width="1063" height="237" alt="Image" src="https://github.com/user-attachments/assets/659de62d-089c-4a98-b7a5-6c80fd6a5bdf" />

I did not change any code because I use docker container.
I installed transformers-5.0.0.dev0 using the following command:
> `pip install git+https://github.com/huggingface/transformers`

Comments:
Hi! I’d like to work on this issue.

@VaishnaviOnPC 
Check this pull request please.. : https://github.com/huggingface/transformers/pull/41552

Should be fixed in main now via #41571, there were multiple PRs for this so a bit confusing. Closing this but ping me if the issue persisted
[Bugfix] Fix quantizer import
Author: kylesayrs
Pull request: yes

## Purpose ##
* Fix bad import in `src/transformers/quantizers/base.py`

## Changes ##
* Import `PreTrainedModel` dynamically, rather than only importing when type checking
  * The class is needed for an `isinstance` check

## Testing ##
* Code which calls `_assign_original_dtype` which was previously failing is now passing
  * Can provide a minimum example if required

Comments:
The code that was working fine until yesterday generates an error with the message below and the model cannot be loaded.
`NameError: name 'PreTrainedModel' is not defined`

<img width="1063" height="237" alt="image" src="https://github.com/user-attachments/assets/f714722b-7f8c-4531-b011-dbc1b689f452" />

please edit

cc @ArthurZucker @Cyrilvallez 

https://github.com/huggingface/transformers/pull/41571

Too many PRs for the same thing 😢 thx for the PR nonetheless
Add conditional checks to _check_and_adjust_attn_implementation()
Author: zheliuyu
Pull request: yes

# What does this PR do?

<!--
Congratulations! You've made it this far! You're not quite done yet though.

Once merged, your PR is going to appear in the release notes with the title you set, so make sure it's a great title that fully reflects the extent of your awesome contribution.

Then, please replace this with a description of the change and which issue is fixed (if applicable). Please also include relevant motivation and context. List any dependencies (if any) that are required for this change.

Once you're done, someone will review your PR shortly (see the section "Who can review?" below to tag some potential reviewers). They may suggest changes to make the code even better. If no one reviewed your PR after a week has passed, don't hesitate to post a new comment @-mentioning the same persons---sometimes notifications get lost.
-->

To prevent unnecessary downloads by kernels, avoid installing kernels-community/flash-attn and kernels-community/vllm-flash-attn3 when attn_implementation=flash_attention_2 is specified for NPU.


## test 

### script
```
from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen3-0.6B",
    device_map="auto",
    torch_dtype="auto",
    attn_implementation="flash_attention_2",
).eval()
print("Operation successful")
```

### Before
```
`torch_dtype` is deprecated! Use `dtype` instead!
Fetching 0 files: 0it [00:00, ?it/s]
Traceback (most recent call last):
  File "/root/kernels-main/src/kernels/utils.py", line 144, in install_kernel
    return _load_kernel_from_path(repo_path, package_name, variant_locks)
  File "/root/kernels-main/src/kernels/utils.py", line 177, in _load_kernel_from_path
    raise FileNotFoundError(
FileNotFoundError: Kernel at path `/root/.cache/huggingface/hub/models--kernels-community--flash-attn/snapshots/90b3e941627659b28ff001c08b218315e1b7183b` does not have build: torch27-cxx11-cann81-aarch64-linux
```

### After
```
`torch_dtype` is deprecated! Use `dtype` instead!
Operation successful
```


Comments:
@ArthurZucker @MekkCyber This PR is now ready for review.

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

This PR fixes three things in `gemma3`:
- a multiple-device error where `torch.where` takes some of its coefficients from a tensor that is not on the right device and is a full_like, so we just replace it with the filling element
- an error in the `flash_attn_inference_equivalence` which is due to the model needing more parameters than are generated by defualt. To avoid this, we add a flag that specifies if we need to check the forward pass with training or not, and make this check default for both and left padding (cc. @vasqu )
- the test `flash_attn_from_config` was failing for the same reasons (`token_type_ids` is required as a model input when training) so I added a `.eval()` to avoid this. It does not seem the model needs to be in train mode for this test, but I can also add an option to the test to only call `.eval()` if a flag is passed

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

run-slow: gemma3

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

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

Even better than main CI :heart: feel free to merge after adding a small comment to why train vs eval

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

run-slow: gemma3
Benchmark overhaul
Author: remi-or
Pull request: yes

This PR overhauls the benchmarking suite that is included in transformers. 
The benchmarking suite is now based around three main components:

- `BenchmarkingConfig` is a dataclass-like object which contains everything needed to reproduce a benchmark on the same machine: input length, generation length, whether to use `kernels` or `compile`, attention implementation, etc. (subject to name change)
- `BenchmarkRunner` is the class that runs the benchmarks defined by the configs, with a given number of measurement iterations, warmup iterations, and a model-id. The runner takes care of setting up the runs in a way that ensures no run interacts with the downstream ones: the model is reloaded, the cache is emptied and the GPU memory is flushed. It also saves the results, the config, and any additional metadata needed to reproduce the benchmark, like hardware information and package versions. 
- The created results files, which contain enough informations to induces (to my knowledge) most of the metrics used to evaluate a model: e2e_atency, tpot, ttft, even inter-token latency. Results also include a sample of what has been generated, which is useful to check if it was gibberish. The results files are in json format and are made to be easily created from the dataclass-like objects and vice versa. 

For now, the new benchmarking suite replaces the `benchmark_v2` part of `transformers` but it could also overwrite the `benchmark` (v1) part. It would be good to make that decision in this PR. And update the CI workflows that rely on the current `benchmark_v2` (putting the PR in draft mode until then).
An example of how to use the new benchmarking suite can be found in `run_benchmarks.py`.

The format of the results file can (and may be bound to) change as we develop tools to analyze them. 
If there is a metric you want to see measured in `transformers`, please leave a comment before this is merged :slightly_smiling_face: 

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41408). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Disable Progress Bar?
Author: haok1402
Pull request: no

Is there a way to disable progress bar in `transformers`?

When I load from pretrained, like the following, the progress bar (i.e. tqdm) can be quite annoying to some applications.

```python
from transformers import AutoTokenizer, AutoModel
from transformers.models.llama.tokenization_llama_fast import LlamaTokenizerFast
from transformers.models.llama.modeling_llama import LlamaModel

NAME = "selfrag/selfrag_llama2_7b"
ragTokenizer: LlamaTokenizerFast = AutoTokenizer.from_pretrained(NAME)
ragPretrined: LlamaModel = AutoModel.from_pretrained(NAME)
```

Related discussion from 4 year ago, which set `tqdm.tqdm = nop` no longer works
- https://github.com/huggingface/transformers/issues/3050

It would be ideal to have a function like `disable_progress_bar`, as provided by `datasets`

```python
import datasets 
datasets.disable_progress_bar()
```

Thanks!

Comments:
My bad, this utility is documented at https://huggingface.co/docs/transformers/v4.40.2/en/main_classes/logging#transformers.utils.logging.disable_progress_bar

You can use it with,

```python3
from transformers.utils.logging import disable_progress_bar
disable_progress_bar()
```

Is there a way to force it to use ASCII based progress bar and not the ipython widget one?

Similar question, in logs/tee tqdm progress bar look bad :(

Is there a way to force the non-repainting version? Or diable tqdm completely?

This is also useful when there are a bunch of parallel processes / ranks writing tqdm progress-bars to the same terminal output

Is there ways to disable IPython progress bar in the notebook
Add beginner-friendly sentiment analysis example
Author: PrajwalDambalkar
Pull request: yes

## What does this PR do?

This PR adds a beginner-friendly sentiment analysis example to help newcomers learn the transformers library. The new example provides a simpler, more educational alternative to the existing `run_glue.py` and `run_classification.py` scripts.

## Motivation and Context

The current text-classification examples (`run_glue.py`, `run_classification.py`) are comprehensive but can be overwhelming for beginners. This educational example fills the gap by:

- **Simplifying the learning curve**: Clear step-by-step workflow with emoji markers
- **Educational focus**: Extensive comments and docstrings explaining each step
- **Quick experimentation**: Options to limit dataset size for faster testing
- **Complete workflow**: From data loading to predictions in one simple script

## Changes Made

### New Files
- **`run_simple_sentiment.py`**: Educational sentiment analysis example using DistilBERT on IMDB dataset
  - Command-line arguments for easy customization
  - Comprehensive logging at each step
  - Example predictions with confidence scores
  - ~300 lines with extensive documentation

- **`test_simple_sentiment.py`**: Unit tests covering:
  - Tokenizer and model loading
  - Preprocessing function
  - Model inference
  - Metrics computation
  - All 5 tests pass 

### Modified Files
- **`README.md`**: Added "Simple Sentiment Analysis (Beginner-Friendly)" section at the top with:
  - Quick start examples
  - Usage instructions
  - Rationale for the example

## Testing
```bash
# All unit tests pass
python examples/pytorch/text-classification/test_simple_sentiment.py
# Result: 5/5 tests passed 

# Tested with small dataset
python run_simple_sentiment.py --max_train_samples 500 --max_eval_samples 100 --num_train_epochs 1
# Result: Training and evaluation completed successfully 
```

## Target Audience

This example is designed for:
- Data scientists new to transformers
- Students learning NLP with deep learning
- Developers wanting a quick introduction before diving into production scripts

## Example Usage
```bash
# Basic usage
python run_simple_sentiment.py

# Quick demo (faster)
python run_simple_sentiment.py --max_train_samples 1000 --max_eval_samples 200

# Custom model
python run_simple_sentiment.py --model_name_or_path bert-base-uncased
```

## Checklist

- [x] Added new beginner-friendly example
- [x] Comprehensive unit tests (5/5 passing)
- [x] Updated README.md with documentation
- [x] Followed transformers coding style
- [x] Clear comments and docstrings
- [x] Tested successfully with small dataset
- [x] Educational value for newcomers

## Additional Notes

This contribution was created as part of an open-source contribution exercise, focusing on adding educational value to the transformers library for newcomers.

Comments:
Standardize RoBERTa model card following issue #36979
Author: MithraVardhan
Pull request: yes

**What does this PR do?**

This PR standardizes the RoBERTa model card following the format established in issue #36979, making it more accessible and user-friendly.

**Changes made:**

✅ **Enhanced Badge Support**
- Added TensorFlow support (orange badge)
- Added Flax support (yellow badge)
- Maintained PyTorch and SDPA badges

✅ **Conversational Description**
- Rewrote in beginner-friendly tone: "RoBERTa is like BERT's smarter cousin"
- Explained key differences in simple terms
- Highlighted practical benefits for sentiment analysis and text classification

✅ **Practical Usage Examples**
- Added sentiment analysis examples with `cardiffnlp/twitter-roberta-base-sentiment-latest`
- Complete AutoModel workflow with confidence scores
- CLI example for command-line usage
- All examples are functional and tested

✅ **Contributor Attribution**
- Added tip box crediting original contributor [Joao Gante](https://huggingface.co/joaogante)

✅ **Comprehensive Resources Section**
- Original paper link (1907.11692)
- Official Facebook AI implementation
- Hugging Face blog posts and guides
- Training documentation links

✅ **Enhanced Notes Section**
- RoBERTa-specific technical details
- Dynamic masking explanation
- Byte-level BPE tokenizer benefits

**Before submitting:**
- [x] I have read the [contributing guidelines](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md)
- [x] I have tested the code examples for syntax errors
- [x] I have verified all links are valid
- [x] I have maintained all existing AutoClass documentation
- [x] I have followed the conversational tone guidelines

**References:**
- Follows the same pattern as PR #37261 (T5), #37585 (SigLIP), #37063 (ELECTRA)
- Addresses issue #36979

@stevhliu for review

Comments:
Enable non-streaming mode in `transformers serve`
Author: LysandreJik
Pull request: yes

Needs this to be merged first: https://github.com/huggingface/transformers/pull/41444

Tests and docs need to be added before undraft

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

Test need a bit of a refactor, which will land once we merge @Wauplin's PR here: https://github.com/huggingface/transformers/pull/41487

I cleaned it up a bit @ArthurZucker; IMO we might want to take a look at simplifying the stream/non-stream path in the future, depending on how the tool handling is done (still needs to be implemented for non-streaming generate and everything CB).