noamaanMulla-03/transformers-issues huggingface dataset:
Fix result retrieval starvation and terminate request-scoped iteration on completion
Author: pythongiant
Pull request: yes

# What does this PR do?

This PR fixes two correctness issues in the continuous batching result consumption logic.

First, it improves `ContinuousBatchingManager.get_result` to avoid starvation and incorrect timeout behavior when multiple requests share a single output queue. Instead of immediately re-queuing mismatched results and returning, the updated logic temporarily defers non-matching outputs while continuing to search for a matching one, reinserting deferred results afterward. This preserves FIFO ordering, ensures fair consumption across requests, and respects the specified timeout under concurrent access.

Second, it fixes `request_id_iter` so that iteration stops when a request reaches a terminal `FINISHED` state, rather than only stopping on cancellation. This prevents infinite iteration after normal request completion and aligns the iterator’s behavior with expected streaming semantics.

These changes are local, backward-compatible, and do not alter the public API or benchmarking behavior.

Fixes #42943 


## 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, Pull Request section?
- [x] Was this discussed/approved via a Github issue or the forum?
- [ ] Did you make sure to update the documentation with your changes?
- [ ] Did you write any new necessary tests?


## Who can review?

@remi-or @ArthurZucker @McPatate


Comments:
View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=42942&sha=b30808

This isn't how we plan to solve the outstanding issue, although I do appreciate you taking a look.

Given we're in a multi threaded context, I was thinking of holding a hashmap of running requests with their req_id as key, and calling get result would wait til completion or timeout. But this may need some careful attention to avoid breaking things.

Feel free to refactor in a direction that looks more like how we intend to address the problem, otherwise we'll close the PR.

> This isn't how we plan to solve the outstanding issue, although I do appreciate you taking a look.
> 
> Given we're in a multi threaded context, I was thinking of holding a hashmap of running requests with their req_id as key, and calling get result would wait til completion or timeout. But this may need some careful attention to avoid breaking things.
> 
> Feel free to refactor in a direction that looks more like how we intend to address the problem, otherwise we'll close the PR.

Instead of pushing everything directly into output_queue maybe we could route through a small dispatcher? would that fit the context more?
Add buffers to `_init_weights` for ALL models
Author: Cyrilvallez
Pull request: yes

# What does this PR do?

## The issue at hand

Currently, during loading we initialize the model on meta device before loading weights, thanks to `init_empty_weights` from `accelerate`.
However, this context manager has BIG drawbacks:
- everything (every parameter and buffer) is first materialized on cpu before being moved to meta device
- this is extremely inefficient of course, as we only want them on meta -> it wastes time and memory
- all buffers stay on cpu (even the persistent ones, that we are loading again after anyway, so don't need to be there...)

This was done like this because BEFORE THIS PR we had no way to reinit non-persistent buffers such as RoPE modules (`XXXRotaryEmbedding` modules) if they were put on meta device.
This PR removes this problem, which will allow me to correctly put everything directly on meta device in a future PR (for convenience as this one is already massive)

## What this PR is doing

This is the first big step towards initializing the full models on meta device natively before loading!
- add the buffers to `_init_weights` for ALL models in the library
- add a test to ensure it is enforced for future models as well
- `_init_weights` is now a complete parameterization of all the model's internal states (parameters AND buffers), allowing to always get back a fully correctly initialized model, independently of any movement to the meta device

Only this change already allows very cool stuff, such as getting back a fully working and initialized model after putting it manually on meta device such as:

```python
with torch.device("meta"):
    model = model_class(config)
# move everything back to cpu (it puts random values everywhere)
model.to_empty(device="cpu")
# Run all the inits, including the buffers -> all buffers are correct here, including ROPE etc
model.init_weights()
```

This was previously impossible, as buffers were NOT re-initialized, so for example ROPE modules would be fully broken, leading to untrainable models.
It can now be trained directly after a simple `init_weights()` call

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42309). 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: afmoe, aimv2, albert, align, altclip, apertus, arcee, aria, bamba, bark, bart, bert, bert_generation, big_bird, bigbird_pegasus, bit

Created some externals functions to avoid duplication for the ones that require several steps!
In general, I STRONGLY AGREE that `_init_weights` is far from ideal, and that something closer to the `reset_parameters`/`reset_buffers` of torch at the module-level would be far simpler! Let's keep it in mind!
Add Phi3.5 Vision Model
Author: yaswanth19
Pull request: yes

Closes #36036

Comments:
cc @zucchini-nlp when you get a chance!

Phi3.5 💀 I will take a look some time this week

@zucchini-nlp PR should be ready for review next week. Will ping you at that time.

@zucchini-nlp PR is ready for initial review 🤗. CI has been broken from weekend but it was all green previously so no issues there.

@zucchini-nlp Ready for another review. The test failures are unrelated and can you please also trigger slow CI here.

@zucchini-nlp Can you trigger the slow tests so that I can push changes for Multi-GPU tests if required and you can do the review later based on your bandwidth.

run-slow: phi3_v

great, reviewing tomorrow!

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

models: ["models/phi3_v"]
quantizations: []

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

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

### Model CI Report

#### ❌ Failed tests

- [phi3_v](https://github.com/huggingface/transformers/actions/runs/19531806328/job/55916944380):
    tests/models/phi3_v/test_modeling_phi3_v.py::Phi3VIntegrationTest::test_model_text_generation
    tests/models/phi3_v/test_modeling_phi3_v.py::Phi3VIntegrationTest::test_model_text_generation_batched
    tests/models/phi3_v/test_modeling_phi3_v.py::Phi3VIntegrationTest::test_model_text_generation_with_multi_image



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

run-slow: auto, phi3_v

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=41977&sha=796319
Fp8 dq
Author: SunMarc
Pull request: yes

# What does this PR do?

This PR extend the dq when users don't have compute capability >= 8.9 for fp8. 

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42926). 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: finegrained_fp8
[Quantization] Removing misleading int8 quantization in Finegrained FP8
Author: MekkCyber
Pull request: yes

# What does this PR do?

instead of falling to int8 quantization, which we don't do for now since we validate that the environment has a `8.9` compute capability at least, we just ask the user to use an other quantization method

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

run-slow: finegrained_fp8

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42945). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
🚨 Fix ConvNeXt image processor default interpolation to BICUBIC
Author: lukepayyapilli
Pull request: yes

## Summary
- Fix default interpolation from BILINEAR to BICUBIC in both `ConvNextImageProcessor` and `ConvNextImageProcessorFast` to match the original ConvNeXt implementation
- Update conversion script to explicitly use BICUBIC
- Add regression test to verify default interpolation

## Details
The original ConvNeXt implementation uses BICUBIC interpolation for image preprocessing:
https://github.com/facebookresearch/ConvNeXt/blob/main/datasets.py

However, both HuggingFace `ConvNextImageProcessor` and `ConvNextImageProcessorFast` defaulted to BILINEAR, causing subtle differences in preprocessing outputs compared to the original implementation.

## Changes
- `image_processing_convnext.py`: Changed default `resample` from `BILINEAR` to `BICUBIC`
- `image_processing_convnext_fast.py`: Changed default `resample` from `BILINEAR` to `BICUBIC`
- `convert_convnext_to_pytorch.py`: Explicitly use `BICUBIC` with reference comment
- `test_image_processing_convnext.py`: Added `test_default_interpolation_is_bicubic` test

## Test plan
- [x] Verified default resample is now `PILImageResampling.BICUBIC` for both slow and fast processors
- [x] Verified existing tests pass (15 passed locally)
- [x] Added new test `test_default_interpolation_is_bicubic`

Fixes part of #28180

Comments:
cc @molbap @yonigozlan 

run-slow: convnext

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42934). 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: convnext
Load generation config from nested configs
Author: zucchini-nlp
Pull request: yes

# What does this PR do?

Fixes https://github.com/huggingface/transformers/issues/42794. The issue was that model's generation params are saved in text config, but we couldn't call `config.get_text_config()` on a dict object. We can delete the second `load_pretrained` because each model gets a default generation config from model config in `__init__`

We could technically get the text config from dict, but I don't see a reason for adding more code if we can delete redundant blocks 


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

run-slow: t5, bart, mbart, umt5

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

models: ["models/bart", "models/mbart", "models/t5", "models/umt5"]
quantizations: []

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

### Model CI Report

#### ❌ Failed tests

- [bart](https://github.com/huggingface/transformers/actions/runs/20334472963/job/58418081979):
    tests/models/bart/test_modeling_bart.py::FastIntegrationTests::test_xsum_1_1_batch_generation
    tests/models/bart/test_modeling_bart.py::FastIntegrationTests::test_xsum_1_1_generation
    tests/models/bart/test_modeling_bart.py::BartModelIntegrationTests::test_decoder_attention_mask

- [mbart](https://github.com/huggingface/transformers/actions/runs/20334472963/job/58418082031):
    tests/models/mbart/test_modeling_mbart.py::MBartEnroIntegrationTest::test_enro_generate_batch



super weird, I am getting a failure with these test cases even on main branch. Will try also by ssh-ing to runners

edit: i am blind, i was using an incorrect python env and thus checking against this same branch 🤦🏻  

run-slow: t5, bart, mbart, umt5, llama, gemma3, mistral

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

models: ["models/bart", "models/gemma3", "models/llama", "models/mbart", "models/mistral", "models/t5", "models/umt5"]
quantizations: []

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

✅ No failing test specific to this PR 🎉 !



run-slow: t5, bart, mbart, umt5, llama, gemma3, mistral



Didn't see that slow tests were triggered. All pass, merging!
`decoder_start_token_id` or `bos_token_id` has to be defined for encoder-decoder generation.
Author: jiqing-feng
Pull request: no
Labels: name: bug

### System Info

latest transformers

### Who can help?

@zucchini-nlp 

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

```python
import torch
from transformers import pipeline

pipe = pipeline(
    "document-question-answering",
    model="naver-clova-ix/donut-base-finetuned-docvqa",
    dtype=torch.float16,
)

image = "https://huggingface.co/spaces/impira/docquery/resolve/2359223c1837a7587402bda0f2643382a6eefeab/invoice.png"
question = "What is the invoice number?"

result = pipe(image=image, question=question)
print(result)
```

error:
```
Traceback (most recent call last):
  File "/home/jiqingfe/transformers/test_dqa.py", line 13, in <module>
    result = pipe(image=image, question=question)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jiqingfe/transformers/src/transformers/pipelines/document_question_answering.py", line 310, in __call__
    return super().__call__(inputs, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jiqingfe/transformers/src/transformers/pipelines/base.py", line 1278, in __call__
    return next(
           ^^^^^
  File "/home/jiqingfe/transformers/src/transformers/pipelines/pt_utils.py", line 126, in __next__
    item = next(self.iterator)
           ^^^^^^^^^^^^^^^^^^^
  File "/home/jiqingfe/transformers/src/transformers/pipelines/pt_utils.py", line 271, in __next__
    processed = self.infer(next(self.iterator), **self.params)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jiqingfe/transformers/src/transformers/pipelines/base.py", line 1185, in forward
    model_outputs = self._forward(model_inputs, **forward_params)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jiqingfe/transformers/src/transformers/pipelines/document_question_answering.py", line 468, in _forward
    model_outputs = self.model.generate(**model_inputs, **generate_kwargs)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/sgl-workspace/miniforge3/lib/python3.12/site-packages/torch/utils/_contextlib.py", line 120, in decorate_context
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/home/jiqingfe/transformers/src/transformers/generation/utils.py", line 2551, in generate
    self._prepare_special_tokens(generation_config, kwargs_has_attention_mask, device=device)
  File "/home/jiqingfe/transformers/src/transformers/generation/utils.py", line 2145, in _prepare_special_tokens
    raise ValueError(
ValueError: `decoder_start_token_id` or `bos_token_id` has to be defined for encoder-decoder generation.
```

### Expected behavior

Cannot locate which PR caused this regression because too many errors recently. The transformers 4.57.3 works well on the script.

Comments:
Caused by https://github.com/huggingface/transformers/pull/41695/, will fix
[docs] dtype
Author: stevhliu
Pull request: yes

update the model loading docs to clarify that `"auto"` is the default now in `from_pretrained`

Comments:
View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=42883&sha=324cde

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42883). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Make `backbone_config` param of vision models configs expect `Any` instead of `dict | None`
Author: simonreise
Pull request: no
Labels: name: Feature request

### Feature request

Some of vision models configs expect `backbone_config` to be `Any` type, and some expect it to be `dict | None`.

However, `backbone_config` actually accepts not only dicts, but model configs too, but providing a config to a `backbone_config` will make linter show a warning, which is a little bit misleading.

### Motivation

Some of vision models (ConditionalDetr, Detr, UperNet) configs expect `backbone_config` to be `Any` type, and some (Mask2Former, MaskFormer, OneFormer) expect it to be `dict | None`.

However, `backbone_config` actually accepts not only dicts, but initialized configs too.

For example, user can create model config like this:
```py
backbone = transformers.ConvNextConfig(
    image_size=input_shape,
    num_channels=input_dims,
    out_features=["stage1", "stage2", "stage3", "stage4"],
)
config = transformers.MaskFormerConfig(
    backbone_config=backbone,
    num_labels=num_classes,
    **kwargs,
)
```
and it will definitely work and be legit, but linter would show a warning `"Expected type 'dict | None', got 'ConvNextConfig' instead"`

### Your contribution

Why not just make all model configs that have `backbone_config` arg expect `Any` type inputs?

I can submit a PR if needed

Comments:
I have been wanting to clean a bit `backbone_config` logic for a long time, unfortunately didn't have time. Ideally we should be able to process a dict or a `PreTrainedConfig` type in all models, though some models might not be handling it
@simonreise if you want to make a PR, I'd recommend to first make sure that the model config handles it well when backbone config is `PreTrainedConfig`. Then you can adjust the type hint to `dict | PreTrainedConfig | None`
fix(tvp): add missing type_vocab_size parameter to TvpConfig
Author: majiayu000
Pull request: yes

## Summary
- Fixes #42925
- The `type_vocab_size` parameter was missing from `TvpConfig`, causing `AttributeError` when instantiating `TvpModel`
- Added the parameter with default value of 2, which matches all TVP models on Hugging Face Hub

## Test plan
- [x] Existing tests should pass (this adds a default value that matches existing models)

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

run-slow: tvp

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

Glad I could help.
[Quantization] From config Quantization for FP8
Author: MekkCyber
Pull request: yes

# What does this PR do?

Make the FP8 logic accessible from `from_config` instead of having to call `from_pretrained`


Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42944). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
[audio] standardize conv output length computation
Author: eustlb
Pull request: no
Labels: name: Audio

As discussed offline with @ArthurZucker , there's a lot f audio models that require knowledge off conv1d output length (eg for mask length computation). For this reason, exact formula for such is duplicated and rewritten at each integration... let's standardize! 

Comments:
Hello @eustlb my PR seems ok from the tests. I used the generalized version. I think I didn't forget any model.

```python
def _conv_out_length(input_length, kernel_size, stride, pad=0, dilation=1):
    # 1D convolutional layer output length formula taken
    # from https://pytorch.org/docs/stable/generated/torch.nn.Conv1d.html
    return torch.div(input_length + 2 * pad - dilation * (kernel_size - 1) - 1, stride, rounding_mode="floor") + 1
```

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.
[audio] standardization tracker
Author: eustlb
Pull request: no
Labels: name: Audio

This issue is a tracker for audio-related standardisation efforts across the library.

_**to be updated...**_
<img width="2000" height="1000" alt="Image" src="https://github.com/user-attachments/assets/383bcebd-0e98-4af1-a076-473e3f7c41f4" />

Efforts:
- [ ] #41202
- [x] #42064
- [x] #42118 

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.
Trainer code is tightly coupled with backend/hardware specific calls
Author: quic-meetkuma
Pull request: no

Current version of Trainer and its ecosystem of code is tightly coupled with the backend hardware. If someone needs to register their backend to Trainer class, then we may need to edit the source code, which is a bad design. Code should be extended rather than edited. The original Trainer was derived from pytorch-lightning and that had nice device/backend registration abstraction. Why can't we enforce the same here?

Below are few references, but I am sure there will be many such references.
Ref:
- https://github.com/huggingface/transformers/blob/8012f80f722044fd0dda45b4034f89fffc2ff344/src/transformers/trainer.py#L3026
- https://github.com/huggingface/transformers/blob/8012f80f722044fd0dda45b4034f89fffc2ff344/src/transformers/trainer.py#L3152
- https://github.com/huggingface/transformers/blob/8012f80f722044fd0dda45b4034f89fffc2ff344/src/transformers/trainer_utils.py#L93
- https://github.com/huggingface/transformers/blob/8012f80f722044fd0dda45b4034f89fffc2ff344/src/transformers/trainer_utils.py#L464
- https://github.com/huggingface/transformers/blob/8012f80f722044fd0dda45b4034f89fffc2ff344/src/transformers/trainer_utils.py#L539
- https://github.com/huggingface/transformers/blob/8012f80f722044fd0dda45b4034f89fffc2ff344/src/transformers/trainer_utils.py#L563
- https://github.com/huggingface/transformers/blob/8012f80f722044fd0dda45b4034f89fffc2ff344/src/transformers/trainer_utils.py#L600
- https://github.com/huggingface/transformers/blob/8012f80f722044fd0dda45b4034f89fffc2ff344/src/transformers/trainer_utils.py#L624

Comments:
cc @sunmarc

Hi,
Any updates on this issue?

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.