noamaanMulla-03/transformers-issues huggingface dataset:
[`chore`] Add missing r-prefix to Gemma3nAudioEncoderModelOutput
Author: tomaarsen
Pull request: yes

# What does this PR do?

This PR adds a required `r`-prefix to a docstring. It'll be added automatically via `utils/check_docstrings.py` if you've made changes in gemma3n, but we should just get ahead of that and fix it now.

It wasn't spotted previously as I believe the `check_docstrings.py` might only run on files that have local changes?

## 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?

@vasqu

- Tom Aarsen

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

run-slow: gemma3n

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

> It wasn't spotted previously as I believe the check_docstrings.py might only run on files that have local changes?

It doesn't run on modular files, I've been trying to make it work in the past and forgot about it with v5 😢 

> It doesn't run on modular files, I've been trying to make it work in the past and forgot about it with v5 😢

Ahh, that's it! Thanks for the intel.

- Tom Aarsen
Fix broken SAM and SAM-HQ due to tie weights and type validation
Author: yonigozlan
Pull request: yes

It looks like these models have been broken for a while due to incorrectly tie weights after the tie weight refactor, and more recently due to enforced typing in the processors

This PR replaces buffers that we can't tie anymore by nn.Parameters, and fixed the typing in processors

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

run-slow: edgetam, edgetam_video, sam, sam2, sam2_video, sam3_tracker, sam3_tracker_video, sam_hq

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43420). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Add Music Flamingo
Author: lashahub
Pull request: yes
Labels: name: New model

name: Audio

This PR adds support for **Music Flamingo**, NVIDIA's open large audio-language model designed for deep music understanding and reasoning.

- **Paper**: [Music Flamingo: Scaling Music Understanding in Audio Language Models](https://huggingface.co/papers/2511.10289)
- **Model Weights**: [nvidia/music-flamingo-2601-hf](https://huggingface.co/nvidia/music-flamingo-2601-hf)
- **Demo**: [Music Flamingo Demo](https://huggingface.co/spaces/nvidia/music-flamingo)
- **Project Page**: [NVIDIA Research](https://research.nvidia.com/labs/adlr/MF/)

Built on [Audio Flamingo 3](https://huggingface.co/docs/transformers/main/en/model_doc/audioflamingo3), Music Flamingo specializes in music analysis and long-form audio reasoning, extending maximum audio support to 20 minutes (vs. 10 minutes in AF3) via **Rotary Time Embeddings (RoTE)**. It also adds a more comprehensive music-focused system prompt, introduces audio boundary tokens (`
`, `
`) for better audio sequence modeling.

It introduces:

* `MusicFlamingoForConditionalGeneration` model class
* `MusicFlamingoProcessor` for preprocessing text + audio
* `MusicFlamingoEncoder` with RoTE for extended temporal modeling
* Configuration, modeling, and processing utilities
* Tests and docs

Music Flamingo can be loaded directly from the Hugging Face Hub:

```python
from transformers import MusicFlamingoForConditionalGeneration, AutoProcessor

processor = AutoProcessor.from_pretrained("nvidia/music-flamingo-2601-hf")
model = MusicFlamingoForConditionalGeneration.from_pretrained("nvidia/music-flamingo-2601-hf", device_map="auto")

conversation = [{
    "role": "user",
    "content": [
        {"type": "text", "text": "Describe this track in detail - genre, tempo, key, instruments, and mood."},
        {"type": "audio", "path": "song.mp3"}
    ]
}]

inputs = processor.apply_chat_template(conversation, tokenize=True, add_generation_prompt=True, return_dict=True).to(model.device)
outputs = model.generate(**inputs, max_new_tokens=500)
print(processor.batch_decode(outputs[:, inputs.input_ids.shape[1]:], skip_special_tokens=True))
# Example: "This energetic Eurodance track at 150 BPM in E major features bright synth arpeggios..."
```

Comments:
cc @ebezzam @eustlb 

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

run-slow: audioflamingo3, auto, musicflamingo

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=43174&sha=ebf318
Fix PEFT x MoEs
Author: ArthurZucker
Pull request: yes

# What does this PR do?
Fixes #42491

This should serve as an example of how the weight loader can be re-used in other project. 
The content is probably gonna be upstreamed to peft!
Current status:
<img width="963" height="396" alt="image" src="https://github.com/user-attachments/assets/728a6594-6ab8-48a1-b3cc-09e89720d286" />

What to expect:
1. You already loaded a transformers model
2. You want to load only the Peft adapters:
    a. we check the weight conversion mapping
    b. if there are ops, we replace them with mapped peft ops
    c. we just collect lora_A and lora_B together, process them like so:
```python
class PeftConcatenate(Concatenate):
    """Convert per-expert LoRA weights to merged MoE weights using SVD."""
    @torch.no_grad
    def convert(
        self, input_dict: dict[str, list[torch.Tensor]], source_patterns: list[str], target_patterns: list[str], **kwargs
    ) -> dict[str, list[torch.Tensor]]:
        lora_a_out = []
        lora_b_out = []
        for k,v in input_dict.items():
            if "lora_A" in k:
                lora_a_out.append(v)
            elif "lora_B" in k:
                lora_b_out.append(v)
        lora_a_out = torch.cat(lora_a_out, dim=0)
        for i in range(len(lora_b_out)):
            lora_b_out.append(torch.block_diag(lora_b_out[0][i], lora_b_out[1][i]))
        lora_b_out = torch.stack(lora_b_out[2:], dim=0)
        return {
            target_patterns[0]+".lora_A.weight": [lora_a_out],
            target_patterns[0]+".lora_B.weight": [lora_b_out],
        }
```

        d. The output fused gate_up.lora_A/B are loaded in the model

CF: (Credits to @BenjaminBossan for the pic)
<img width="779" height="1710" alt="image" src="https://github.com/user-attachments/assets/634c3ffa-e984-437e-a10f-7c9718ac3515" />



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

Just leaving some general comments on this PR:

1. I wouldn't override `__setattr__` in `WeightTransform`, as it's error prone. Instead, change `source_patterns` and `target_patterns` to `@property` with an appropriate `@setter` and move the logic there.
2. The `hotswap` code path has been removed from `load_adapter`, it needs to be added back in.
3. Similarly, there was a `if peft_config.inference_mode: self.eval()` call there that's now missing.
4. As discussed, the currently hard-coded Mixtral conversion ops need to be moved to a mapping that is only called for Mixtral.
5. We should add some sanity checks, e.g. if the expert layer is targeted and the PEFT adapter is not LoRA, raise a helpful error message.


Hotswap was explicitly removed, we can bring it back later on but its a bit hard to get it done with the new converter / I think the way we load the weights natively supports that

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=43261&sha=92d0fa
Fix flaky SAM-HQ integration tests
Author: engmohamedsalah
Pull request: yes

## Summary

Fixes #42890 

SAM-HQ integration tests were failing due to non-deterministic positional embeddings. The `positional_embedding` parameter in `SamHQPositionalEmbedding` is:
1. Randomly initialized using `torch.randn()` (line 418 in `modeling_sam_hq.py`)
2. Excluded from checkpoint loading via `_keys_to_ignore_on_load_missing` (line 1236)

This meant every test run generated different random values, causing flaky test failures.

## Solution

Added `set_seed(0)` in the `setUp()` method of `SamHQModelIntegrationTest` class to ensure deterministic random initialization across all integration tests.

This approach:
- ✅ **KISS**: Single line in setUp() method
- ✅ **DRY**: One fix applies to all 14 integration test methods
- ✅ **Clean**: Follows existing transformers testing patterns
- ✅ **Minimal**: Only 8 lines added (including comments)

## Changes

- Added `from transformers.trainer_utils import set_seed` import
- Added `setUp()` method with `set_seed(0)` to `SamHQModelIntegrationTest` class
- Added clear comments explaining why seed is needed

## Test Plan

- [x] Python syntax check passed
- [ ] Integration tests will be run by CI

Comments:
As mentioned [here](https://github.com/huggingface/transformers/issues/42890#issuecomment-3739434107) I'm not certain setting the seed is the right solution, and the test failure might indicate an actual issue with weight loading somewhere. Holding off on merging this until it's investigated!

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

run-slow: sam_hq

Thank you @Rocketknight1 for catching this! You were absolutely right - this is a **weight loading bug**, not just a randomness issue.

## Root Cause Analysis

Commit `0b369802cf` ("fix sam family!") removed `_tied_weights_keys` because positional embeddings are buffers (not parameters) and can't be tied. However, the commit left `_keys_to_ignore_on_load_missing` in place, which causes `prompt_encoder.shared_embedding.positional_embedding` to be **randomly initialized on every model load** instead of being loaded from the checkpoint.

The flaky tests were actually **exposing this bug** - outputs varied because one embedding was randomly initialized each time!

## Proper Fix

I've created a new PR with the correct fix: removing `_keys_to_ignore_on_load_missing` entirely so both positional embeddings are properly loaded from checkpoint.

The new PR: #TBD (will update once created)

Closing this PR in favor of the proper fix. Thank you again for the thorough review!

Update: New PR with proper fix is #43463
Saving bug using FSDP 2.0 + parallelism_config set (while works fine without providing parallelism_config in TrainingArguments)
Author: d5031
Pull request: no

The reason is the order of elifs here 

https://github.com/huggingface/transformers/blob/main/src/transformers/trainer.py#L4024

        elif getattr(self.accelerator, "parallelism_config", None) is not None:
            # DeepSpeed SP already handles checkpoint saving below, so skip manual save in that case
            pc = getattr(self.accelerator, "parallelism_config")
            if self.accelerator.should_save_model and not (pc.sp_enabled and pc.sp_backend == "deepspeed"):
                self._save(output_dir)
        # If we drop to here, we're in 1D parallelism, so all ranks need to go to `save_pretrained`
        elif (tp_size := getattr(self.model, "_tp_size", 0)) is not None and tp_size > 1:
            self._save(output_dir)
        elif self.is_fsdp_enabled:
            if "FULL_STATE_DICT" in str(self.accelerator.state.fsdp_plugin.state_dict_type):
                state_dict = self.accelerator.get_state_dict(self.model)
                if self.args.should_save:
                    self._save(output_dir, state_dict=state_dict)

So, as a result it runs self._save(output_dir) which fails (for another reason), but point is that it should NOT run _save at all (which it doesn't with is_fsdp_enabled and sharding) 


Comments:
cc @SunMarc 

Thanks ! TBH, this logic is not really useful and only creates issues. Would you like to open a PR to remove that @d5031 ? 

```python
 # We are in N-D parallelism if we have parallelism_config set, so we check accelerate if we're on a to_save rank
        elif getattr(self.accelerator, "parallelism_config", None) is not None:
            # DeepSpeed SP already handles checkpoint saving below, so skip manual save in that case
            pc = getattr(self.accelerator, "parallelism_config")
            if self.accelerator.should_save_model and not (pc.sp_enabled and pc.sp_backend == "deepspeed"):
                self._save(output_dir)
        # If we drop to here, we're in 1D parallelism, so all ranks need to go to `save_pretrained`
        elif (tp_size := getattr(self.model, "_tp_size", 0)) is not None and tp_size > 1:
            self._save(output_dir)
```

Many thanks for checking and coming back on this, @SunMarc !

Tbh, i'd be happy if someone more familiar with codebase would make a change (if OK). Thank you.

Btw, i've opened few more issues recently in transformers/accelerate (and 99.9%+ they are all real, but awfully sorry for a bit lazy approach / no small reproducer)


I can work on it and create a PR to fix the same. cc @SunMarc @d5031 

updated, please take a look at it when you get a chance @SunMarc 
https://github.com/huggingface/transformers/pull/43314
fix gguf recent conversion issues
Author: ArthurZucker
Pull request: yes

# What does this PR do?
Fixes #43452

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

run-slow: qwen2

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

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=43465&sha=d68934
Upgrade GitHub Actions to latest versions
Author: salmanmkc
Pull request: yes

## Summary
This PR upgrades GitHub Actions to their latest versions for Node.js 24 compatibility and security updates.

## Changes

| Action | Old Version(s) | New Version | Files |
|--------|---------------|-------------|-------|
| conda-incubator/setup-miniconda | v2 | v3 | release-conda.yml |
| docker/build-push-action | v3, v5 | v6 | build-ci-docker-images.yml, build-docker-images.yml, build-nightly-ci-docker-images.yml, build-past-ci-docker-images.yml |
| docker/login-action | v2 | v3 | build-nightly-ci-docker-images.yml, build-past-ci-docker-images.yml |
| docker/setup-buildx-action | v2 | v3 | build-nightly-ci-docker-images.yml, build-past-ci-docker-images.yml |
| slackapi/slack-github-action | 6c661ce58804a1a20f6dc5fbee7f0381b469e001 | 91efab103c0de0a537f72a35f6b8cda0ee76bf0a | check_failed_tests.yml, new_model_pr_merged_notification.yml |

## Why these changes?
- Keeps actions up to date with latest stable releases
- Updated actions include security fixes and new features

## Testing
These changes only update action versions and don't modify workflow logic.


Comments:
cc @ydshieh
Upgrade GitHub Actions for Node 24 compatibility
Author: salmanmkc
Pull request: yes

## Summary
This PR upgrades GitHub Actions to their latest versions for Node.js 24 compatibility and security updates.

## Changes

| Action | Old Version(s) | New Version | Files |
|--------|---------------|-------------|-------|
| actions/cache | v4 | v5 | add-model-like.yml |
| actions/checkout | v4, v5 | v6 | add-model-like.yml, assign-reviewers.yml, benchmark.yml, benchmark_v2.yml, build-ci-docker-images.yml, build-docker-images.yml, build-nightly-ci-docker-images.yml, build-past-ci-docker-images.yml, check_tiny_models.yml, circleci-failure-summary-comment.yml, collated-reports.yml, doctests.yml, model_jobs_intel_gaudi.yml, new_model_pr_merged_notification.yml, pr-repo-consistency-bot.yml, pr_slow_ci_suggestion.yml, push-important-models.yml, release-conda.yml, release.yml, self-comment-ci.yml, self-scheduled-intel-gaudi.yml, self-scheduled.yml, slack-report.yml, stale.yml, trufflehog.yml, update_metdata.yml |
| actions/download-artifact | v4 | v7 | check_failed_tests.yml, collated-reports.yml, doctests.yml, pr-repo-consistency-bot.yml, release.yml, self-scheduled.yml, slack-report.yml |
| actions/github-script | v6, v7 | v8 | check_failed_tests.yml, circleci-failure-summary-comment.yml, get-pr-info.yml, pr-repo-consistency-bot.yml, pr_slow_ci_suggestion.yml, push-important-models.yml |
| actions/setup-python | v4, v5 | v6 | assign-reviewers.yml, check_tiny_models.yml, circleci-failure-summary-comment.yml, pr-repo-consistency-bot.yml, release.yml, self-scheduled-intel-gaudi.yml, stale.yml |
| actions/upload-artifact | v4 | v6 | add-model-like.yml, check_failed_tests.yml, check_tiny_models.yml, doctest_job.yml, doctests.yml, model_jobs.yml, model_jobs_intel_gaudi.yml, pr-repo-consistency-bot.yml, release.yml, self-nightly-caller.yml, self-scheduled-caller.yml, self-scheduled-flash-attn-caller.yml, self-scheduled-intel-gaudi.yml, self-scheduled.yml, slack-report.yml |

## Why these changes?
- Keeps actions up to date with latest stable releases
- Updated actions include security fixes and new features

## Testing
These changes only update action versions and don't modify workflow logic.


Comments:
cc @ydshieh
Sanitize invalid UTF‑16 surrogate codepoints before calling the Rust encode_batch, replacing them with U+FFFD
Author: josephrocca
Pull request: yes

Without this fix, this crashes:
```py
from transformers import T5TokenizerFast
tok = T5TokenizerFast.from_pretrained("t5-small")
tok("ok" + "\ud800" + "bad")
```

The error message implies a wrong input type: `TypeError: TextEncodeInput must be Union[TextInputSequence, Tuple[InputSequence, InputSequence]]` - but the input is a valid Python `str`.

Last known working version: v4.44.2 (tokenizers v0.19.1)

## Who can review?

@ArthurZucker and @itazap


Comments:
@ArthurZucker Ah, sorry about that. I'll close this an open a PR over there. I noticed that for *non-fast* tokenizers:

* BertTokenizer: does not crash, tokenizes to ['ok', '##bad'] and encodes to [101, 7929, 9024, 102]
* T5Tokenizer (SentencePiece): raises TypeError: not a string

Is there a "correct" way to handle this (at the Python-bindings level) from your perspective RE the tokenizers PR? Or should fast tokenizers match the slow ones on a per-class level?

There is no longer any `Fast` and slow tokenizers in `v5`! thus is there is such an issue it would need a fix in `tokenizers`!
Unexpected tokenizer behavior difference from v4 to v5
Author: awni
Pull request: no
Labels: name: bug

```python
from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained('mlx-community/Llama-3.2-1B-Instruct-4bit')

text = tokenizer.decode([128000, 64, 1174, 65])
print(text)
```

For 4.57.3 you get `
a,b`
For 5.0.0rc1 you get `
a ,b`

Is it expected the behavior changed here?

### Reproduction

Run the snippet above

### Expected behavior

The two should have the same behavior right?

Comments:
Hi, I got the same issue: https://github.com/huggingface/transformers/issues/42898

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.
ImportError: cannot import name 'Qwen2_5_VLImageProcessor' from 'transformers.models.qwen2_5_vl' (/usr/local/lib/python3.10/dist-packages/transformers/models/qwen2_5_vl/__init__.py)
Author: LaoWangGB
Pull request: no
Labels: name: bug

### System Info

vllm==0.7.2
transformers==4.49.0

### Who can help?

ImportError: cannot import name 'Qwen2_5_VLImageProcessor' from 'transformers.models.qwen2_5_vl' (/usr/local/lib/python3.10/dist-packages/transformers/models/qwen2_5_vl/__init__.py)

### Information

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

from vllm import LLM
model = LLM(model="Qwen2.5-VL-7B, trust_remote_code=True, dtype="bfloat16")

### Expected behavior

I confirm the version:4.49.0_dev contains a script named image_processing_qwen2_5_vl.py, but version 4.49.0 remove it.
ImportError: cannot import name 'Qwen2_5_VLImageProcessor' from 'transformers.models.qwen2_5_vl' (/usr/local/lib/python3.10/dist-packages/transformers/models/qwen2_5_vl/__init__.py)


Comments:
i add Qwen2VLImageProcessor， it‘s work.

![Image](https://github.com/user-attachments/assets/6b575d7d-53b1-48e2-ba72-202033084fac)

![Image](https://github.com/user-attachments/assets/975a363f-78ce-4e17-b0e5-ea47f30fa1e7)

Hey!

This is a duplicate of https://github.com/huggingface/transformers/issues/36193. Yes, the class was removed since we want to enable fast processing for Qwen2-5-VL (same was for qwen2-vl). The image processors of the two models are identical, so you can safely use `Qwen2VLImageProcessor`

The official checkpoints are already modified, if you are using a fine-tune please change the `preprocessor_config.json`

> i add Qwen2VLImageProcessor， it‘s work.
> 
> ![Image](https://github.com/user-attachments/assets/6b575d7d-53b1-48e2-ba72-202033084fac)
> 
> ![Image](https://github.com/user-attachments/assets/975a363f-78ce-4e17-b0e5-ea47f30fa1e7)

I found that the vllm has fixed this problem in [https://github.com/vllm-project/vllm/pull/13286](https://github.com/vllm-project/vllm/pull/13286), But the release version has not been released yet, so installing the latest vllm（from github） should also solve this problem.

> i add Qwen2VLImageProcessor， it‘s work.
> 
> ![Image](https://github.com/user-attachments/assets/6b575d7d-53b1-48e2-ba72-202033084fac)
> 
> ![Image](https://github.com/user-attachments/assets/975a363f-78ce-4e17-b0e5-ea47f30fa1e7)

thx

it works when upgrade transformer version to 4.50