noamaanMulla-03/transformers-issues huggingface dataset:
Fix Mixtral: Docstring uses consistent 'top_k_index' and 'top_k_weights' in MixtralSparseMoeBlock
Author: ShivanshTiwari1
Pull request: yes

# What does this PR do?

This PR resolves a **minor documentation inconsistency** found in the `MixtralSparseMoeBlock.forward` method located in `src/transformers/models/mixtral/modular_mixtral.py`.

The function definition correctly uses the parameters **`top_k_index`** and **`top_k_weights`**, but the docstring incorrectly referenced them as `selected_experts` and `routing_weights`.

This update ensures the documentation is accurate, which is crucial for code clarity and for any models that inherit this MoE block.

---
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).
- [ ] 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. (The linked issue shows approval.)
- [x] Did you make sure to update the documentation with your changes? (The change is the documentation update itself.)
- [ ] Did you write any new necessary tests?

## Who can review?

@ArthurZucker (As tagged in the original issue thread)

Comments:
Hi @ShivanshTiwari1 the fixes look okay, but there are a lot of unrelated style changes in the code! Try to revert those, or do `pip install -e .[quality]` to get the style tools yourself and run `make fixup` or `make style` to ensure the code matches our formatting rules.

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

run-slow: mixtral
Fix continuous batching tests
Author: Rocketknight1
Pull request: yes

The continuous batching tests call `apply_chat_template` and broke due to the changed default args in https://github.com/huggingface/transformers/pull/41626. This was a real problem because those tests spin up threads via the `Manager` class, which I think persisted as zombie threads as a result (there was a lot of memory usage and very slow cleanup after these failures).

This PR fixes the tests and hopefully also the rest of our generation CI!

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

@ydshieh The problem is that `add_request` expects just `input_ids`, and breaks when you pass the whole tokenizer dict. It's possible that some user workflows might break because of this, but it should be easy to fix. We knew this change would break backward compatibility a little bit (which is why it waited for v5)!
add back `logging_dir`
Author: SunMarc
Pull request: yes

# What does this PR do?

This PR adds back `logging_dir` from @BenjaminBossan suggestion. It might be more used than I thought due to its generic name even though users might not be using tensorboard.

Comments:
@bot /style 

Style bot fixed some files and pushed the changes.

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42013). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
`max_pixels` parameter ignored when loading Qwen2VL/Qwen3VL image processors via `from_pretrained()`
Author: ReinforcedKnowledge
Pull request: no
Labels: name: bug

### Bug description

When loading Qwen2VL or Qwen3VL image processors using `from_pretrained()`  with the `max_pixels` parameter, the parameter is accepted without error but silently ignored during image processing. This causes images to be resized using the default `max_pixels=16,777,216` instead of the user-specified value, resulting in significantly higher token counts than expected.



### System Info

- transformers version: 4.57.1 (and likely all previous versions with Qwen2VL/Qwen3VL support)
- Affected models: all models that rely on Qwen2VL's image processor (so Qwen2VL and Qwen3VL)
- CPython version: 3.13
- Platform: Ubuntu 22.04.5 LTS



### Who can help?

@ArthurZucker and @itazap 

### Information

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

### Tasks

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

### Reproduction

### Steps to reproduce
```python
from transformers import Qwen3VLProcessor
from PIL import Image

# Load processor with custom max_pixels
processor = Qwen3VLProcessor.from_pretrained(
    'Qwen/Qwen3-VL-2B-Instruct',
    trust_remote_code=True,
    max_pixels=200_000  # Expect images to be resized to ~200k pixels
)

# Check the internal state
print(f"max_pixels attribute: {processor.image_processor.max_pixels}")
print(f"size['longest_edge']: {processor.image_processor.size['longest_edge']}")

# Process a 2000×2000 image (4M pixels)
test_image = Image.new('RGB', (2000, 2000), color='red')
print(f"Input image: {test_image.size[0]}×{test_image.size[1]} = {test_image.size[0] * test_image.size[1]:,} pixels")

# Further investigations
messages = [{"role": "user", "content": [
    {"type": "image", "image": test_image},
    {"type": "text", "text": "Describe this image."}
]}]

text = processor.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
result = processor(text=text, images=[test_image], return_tensors="pt")

# Check actual processed dimensions
grid_thw = result['image_grid_thw'][0]
temporal, height_patches, width_patches = grid_thw
total_patches = (temporal * height_patches * width_patches).item()
effective_pixels = total_patches * 16 * 16  # Each patch is 16×16 pixels

print(f"Grid (T, H, W): {temporal}×{height_patches}×{width_patches}")
print(f"Total patches: {total_patches}")
print(f"Effective pixels: {effective_pixels:,}")
```

### Expected behavior

- max_pixels attribute: 200000
- size['longest_edge']: 200000
- Input image: 2000×2000 = 4,000,000 pixels
- Grid (T, H, W): 1×26×26
- Total patches: 676
- Effective pixels: 173,056

### Actual behavior:

- max_pixels attribute: 200000
- size['longest_edge']: 16777216
- Input image: 2000×2000 = 4,000,000 pixels
- Grid (T, H, W): 1×124×124
- Total patches: 15376
- Effective pixels: 3,936,256

### Related PR
https://github.com/huggingface/transformers/pull/41954

Comments:
cc @zucchini-nlp @molbap @yonigozlan, see also the PR at #41954
Fix default image_rows and image_cols initialization in Idefics3 and SmolVLM processors
Author: MilkClouds
Pull request: yes

# What does this PR do?

This PR fixes a bug in the default initialization of `image_rows` and `image_cols` in the Idefics3 and SmolVLM processors.

## Problem

The original code incorrectly used `len(text)` to determine the size of the default `image_rows` and `image_cols` lists:
```python
image_rows = inputs.pop("rows", [[0] * len(text)])
image_cols = inputs.pop("cols", [[0] * len(text)])
```

This creates a single list with length equal to the number of text samples in the batch, which is incorrect. The correct behavior should create a list for each sample, where each inner list has length equal to the number of image tokens in that specific sample.

## Solution

Changed the default initialization to count image tokens per sample:
```python
image_rows = inputs.pop("rows", [[0] * sample.count(self.image_token) for sample in text])
image_cols = inputs.pop("cols", [[0] * sample.count(self.image_token) for sample in text])
```

This ensures that:
1. Each sample in the batch gets its own list
2. Each list has the correct length matching the number of image tokens in that sample

## Impact

This fix affects:
- `Idefics3Processor` in `src/transformers/models/idefics3/processing_idefics3.py`
- `SmolVLMProcessor` in `src/transformers/models/smolvlm/processing_smolvlm.py`

The bug would have caused issues when processing batches with multiple samples or samples with multiple images, as the default values would have incorrect dimensions.

## 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.
- [ ] 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?

@zucchini-nlp (multimodal models)



Comments:
p.s. this issue seems to be ignored before because `return_row_col_info` was always given to True to ImageProcessor! I've met error raised when I used non-`SmolVLMImageProcessor` for image processor of SmolVLMProcesor.

For reviewer's information: this PR is ready for review!

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

run-slow: idefics3, smolvlm

Perfect thanks! I'll merge once the CI passes

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

# What does this PR do?

This PR adds a **fast image processor for the GLPN model**, implemented as `GLPNImageProcessorFast`.  

Fixes # (issue)

## Before submitting
- Implements `GLPNImageProcessorFast` using `BaseImageProcessorFast`.
- Adds tests and documentation updates.

### 🧪 Testing
- All tests pass except for the (`test_slow_fast_equivalence_batched`). I would like some help here. 

### 📄 Files updated
- `src/transformers/models/glpn/image_processing_glpn_fast.py`
- `src/transformers/models/glpn/__init__.py`
- `src/transformers/models/auto/image_processing_auto.py`
- `tests/models/glpn/test_image_processing_glpn.py`
- `docs/source/en/model_doc/glpn.md`

## Before submitting
- [x] Read the [contributor guidelines](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request).
- [x] Updated documentation and tests.
- [x] Verified style and quality with `make style` and `make quality`.

## Who can review?

@yonigozlan @molbap


Comments:
> Hey, thanks for starting this! Left some initial comments :)

Thanks a lot for reviewing Pablo! I've made the changes. 

> Thanks for iterating! Did a second review 🤗

Thank you! I've made the changes.

> > Thanks for iterating! Did a second review 🤗
> 
> Thank you! I've made the changes.

Hi! Is there further review required and anything I should change in the implementation? Please let me know. Thank you!

> I left additional comments because I'm not 100% convinced by the padding logic, let's make sure it's needed, and if it is let's use existing methods!

Thanks a lot for reviewing! Appreciate your help. 

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

> Hey @Aravind-11, thanks a lot for working on this! I made some final changes to get this merged. Mostly removed the padding logic so as not to break BC as it wasn't in the original image processor. I'll merge when the CI passes!

Thank you so much @yonigozlan! for the necessary commits and review! Does the failing 'tests_non_model' arise from the pr?

> Thank you so much @yonigozlan! for the necessary commits and review! Does the failing 'tests_non_model' arise from the pr?

I don't think so, I'm seeing it in other PRs...

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

run-slow: auto, glpn
add fuyu fast image processors
Author: DeXtAr47-oss
Pull request: yes

# What does this PR do?

This PR introduces FuyuImageProcessorFast, providing a faster alternative to the original FuyuImageProcessor by leveraging torchvision for image transformations.

Key changes include:

* Implementation of FuyuImageProcessorFast inheriting from BaseImageProcessorFast.
* Updates to tests/models/fuyu/test_image_processing_fuyu.py to include the fast processor, override save/load tests and fixed the image height and width in test_preprocess_with_tokenizer_info have been updated to values divisible by 30 (180x300), ensuring compatibility with FuyuImageProcessorFast and avoiding ValueError: image_height must be divisible by 30. All Fuyu image processing tests now pass.
* Addition of documentation for FuyuImageProcessorFast 

Fixes #36978


## 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. Was this discussed/approved via a Github issue or the forum? [Contributions Welcome] Add Fast Image Processors #36978](https://github.com/huggingface/transformers/issues/36978)

- [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?
@yonigozlan 



Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41817). 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: auto, fuyu
[kernels] Fix XPU layernorm kernel
Author: MekkCyber
Pull request: yes

# What does this PR do?

Adds xpu layernorm kernel after pining the kernel version, and making sure the user has the latest version before registering the mapping that includes xpu device.

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

@SunMarc Hi, can you help review and merge this PR so as we can re-submit https://github.com/huggingface/transformers/pull/41563?

Hey @kaixuanliu, this is not the final fix, I need to refactor some logic to avoid registering the kernel mapping at import time
[v5] Deprecate Text2Text and related pipelines
Author: Rocketknight1
Pull request: yes
Labels: name: for_v5?

Text2Text is mostly used only by older models, and via the Summarization/Translation pipelines. However, all of these tasks are now handled by general-purpose LLMs that provide much higher translation/summarization quality than older single-purpose models. This PR retains the pipelines, but deprecates them with a warning.

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41996). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Qwen2.5-VL  restore tensor multi-image form
Author: NiFangBaAGe
Pull request: no


Hello, I have recently been experimenting with qwen2.5-vl (https://github.com/huggingface/transformers/blob/v4.52-release/src/transformers/models/qwen2_5_vl/modeling_qwen2_5_vl.py). I noticed that multiple images are pre-merged here,
```
image_embeds = self.get_image_features(pixel_values, image_grid_thw)
```
 but I want to process each image individually, such as performing pooling on each image. I found that when I attempt operations like 
```
image_embeds.view(n_img, image_embeds.shape[0]//n_img, -1)
```
 I cannot correctly restore the multi-image format. Could you please advise on how to handle this? 


Comments:
qwen2.5vl use native resolusion, so you should use `image_grid_thw` to recover each image's hiddn.

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.
fix `deeepspeed` in AMD docker file
Author: ydshieh
Pull request: yes

# What does this PR do?

Similar to #41985

[Build](https://github.com/huggingface/transformers/actions/runs/19092684983/job/54546222873) is ✅ now

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42025). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
🔴 [generate] default `max_new_tokens`
Author: gante
Pull request: yes

# What does this PR do?

The default length for `generate`, as of H2 2024, has been implicitly `max_new_tokens=20`. This PR makes it explicit. 

Since we're touching default lengths, it also removes the default `min_length=0` -- it is impossible to hit, the minimum length of all sequences is 1, the bos token.

A few tests were updated in the process -- they were relying on default values. (Failing TF/Jax tests were removed)

Fixes #35765 

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

closing since I'm leaving and this is massively outdated, but this [using `max_new_tokens=20` as default] should be added :) cc @ArthurZucker @Cyrilvallez
🚨 [v5] Remove deprecated cache classes
Author: gante
Pull request: yes

# What does this PR do?

🚨🚨🚨 DO NOT MERGE 🚨🚨🚨
- Depends on #41889

Merging this PR will break `from transformers import Trainer` on the latest PEFT release (`0.17.1`), which in turn breaks our `make fixup` when PEFT is installed. PEFT `main` already sorted this issue ([here](https://github.com/huggingface/peft/commit/41c07f0445879da0e73ca3c682a0c359cd027f50)), but it is yet unreleased as of 7-oct-2025.

cc @BenjaminBossan (chatted on slack -- when `transformers` has a concrete timeline for v5, we can best evaluate an adequate timing for a PEFT release)
cc @Cyrilvallez FYI 

_______________________________

This PR removes the deprecated cache classes in `cache_utils.py`.

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

Oh damn, I had https://github.com/huggingface/transformers/pull/41378 as well doing the same, so I will revert the classes and just remove support for legacy in order to wait for peft! Thanks for letting me know!
Integration of a High-Performance, Real-Time Optimized Sentiment Analysis Model (DeBERTa-v3 + LORA) into Hugging Face Transformers Ecosystem
Author: 3015pavan
Pull request: no
Labels: name: Feature request

### Feature request

I propose adding a new real-time sentiment analysis pipeline based on a fine-tuned DeBERTa-v3 model optimized with LoRA (Low-Rank Adaptation).

This model delivers state-of-the-art sentiment classification accuracy while maintaining low latency and small model size, making it ideal for streaming and production environments.


### Motivation

Existing sentiment models on Hugging Face (e.g, ROBERTAa, BERT, DistilBERT) perform well on static text but

have limitations:

Not optimized for real-time inference

High memory and compute requirements

 Limited domain and multilingual adaptability

No built-in integration for live streaming (eg, social media feeds)

With increasing needs for live sentiment tracking (finance, social media analytics, moderation, brand monitoring), there's a gap for a lightweight yet accurate real-time model.

This feature aims to fill that gap.

### Your contribution

Core Components:

1. Optimized DellERTa -v3 model fine tuned with LuRa on tweet_eval/sentiment and missed-domain data.

2. Pipeline integration into transformer pipeline("sentiment-analysis", model-="optimized sentiment")

3. Optional streaming connector using  websockets for real-time API input (eg: Twitter/X Reddit, Kafka).

4. Hugging Face Space demo (Gradio app) showing live inference and latency benchmarks.

Deliverables:

Model weights: optimized-sentiment-model.

Dataset scripts (TweetEval + Augmented data)

Example scripts: train.py, evaluate.py, predict_stream.py

Documentation + Model Card

Integration tests for pipeline performance.

Comments:
I think this issue has some significant confusion about how the Transformers repo works, you can train and upload that model to the Hub without needing a PR to the core library itself!
Fix tokenizer singleton bug in model_input_names (Issue #42024)
Author: somdipto
Pull request: yes
Labels: name: Code agent slop

## Summary

This PR fixes GitHub issue #42024 by implementing a property-based solution to prevent cross-instance mutations in the tokenizer's `model_input_names` attribute.

## Problem

The original implementation stored `model_input_names` as a mutable class attribute, causing all tokenizer instances to share the same reference. When one instance modified the list, it affected all other instances, leading to unexpected behavior and bugs.

## Solution

Implemented a property-based encapsulation pattern:
- Converted `model_input_names` from a class attribute to an instance property
- Added proper defensive copying to prevent shared references
- Created getter/setter methods with type validation
- Ensured backward compatibility with existing API

## Changes Made

1. **Core Fix** (`transformers/src/transformers/tokenization_utils_base.py`):
   - Replaced mutable class attribute with immutable tuple
   - Added private `_model_input_names` instance variable
   - Implemented property getter/setter with defensive copying
   - Added comprehensive input validation

2. **Test Suite** (861 lines, 31 test cases):
   - Validates buggy behavior reproduction
   - Confirms fix effectiveness  
   - Tests edge cases and serialization
   - 100% pass rate on all test cases

3. **Documentation**:
   - Comprehensive CHANGELOG entry with impact analysis
   - Technical documentation with usage examples
   - Migration guide for users

## Testing

- All 31 test cases pass successfully
- No regression in existing functionality
- Backward compatibility maintained
- Comprehensive edge case coverage

## References

- Fixes #42024
- Implementation follows Python best practices for mutable attribute encapsulation

Comments: