noamaanMulla-03/transformers-issues huggingface dataset:
fix qwen2vl/qwen3vl video processor temporal padding when num_frames%temporal_patch_size!=1
Author: yaogang2060
Pull request: yes

# What does this PR do?
expect qwen3vl video processor can process these two cases:
1. num_frames is 1, and sample_frames is false.
2. num_frames > temporal_patch_size and num_frames % temporal_patch_size != 1

Fixes # (issue)
https://github.com/QwenLM/Qwen3-VL/issues/1689



Comments:
@zucchini-nlp please check this~ 

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

> Member



> LGTM now! Do you plan to update `smart_resize` in this PR or make a separate one?

@JJJYmmm  it's up to you🫡. maybe just use `smart_resize` in qwen2vl?

@yaogang2060 As mentioned in https://github.com/huggingface/transformers/pull/42083#discussion_r2509274897, you can remove the frame number check (or warning) at  
https://github.com/huggingface/transformers/blob/59994f0841f1a3641ced696ebfb477572aabbfcf/src/transformers/models/qwen3_vl/video_processing_qwen3_vl.py#L43-L44
and instead use `ceil` at  
https://github.com/huggingface/transformers/blob/59994f0841f1a3641ced696ebfb477572aabbfcf/src/transformers/models/qwen3_vl/video_processing_qwen3_vl.py#L53
to ensure `t_bar` is never zero.

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

run-slow: qwen2_vl, qwen3_vl

> @yaogang2060 As mentioned in [#42083 (comment)](https://github.com/huggingface/transformers/pull/42083#discussion_r2509274897), you can remove the frame number check (or warning) at
> 
> https://github.com/huggingface/transformers/blob/59994f0841f1a3641ced696ebfb477572aabbfcf/src/transformers/models/qwen3_vl/video_processing_qwen3_vl.py#L43-L44
> 
> 
> and instead use `ceil` at
> https://github.com/huggingface/transformers/blob/59994f0841f1a3641ced696ebfb477572aabbfcf/src/transformers/models/qwen3_vl/video_processing_qwen3_vl.py#L53
> 
> 
> to ensure `t_bar` is never zero.



> @yaogang2060 As mentioned in [#42083 (comment)](https://github.com/huggingface/transformers/pull/42083#discussion_r2509274897), you can remove the frame number check (or warning) at
> 
> https://github.com/huggingface/transformers/blob/59994f0841f1a3641ced696ebfb477572aabbfcf/src/transformers/models/qwen3_vl/video_processing_qwen3_vl.py#L43-L44
> 
> 
> and instead use `ceil` at
> https://github.com/huggingface/transformers/blob/59994f0841f1a3641ced696ebfb477572aabbfcf/src/transformers/models/qwen3_vl/video_processing_qwen3_vl.py#L53
> 
> 
> to ensure `t_bar` is never zero.

just removed~
Standardize conv len function for audio models
Author: diegoakel
Pull request: yes

# What does this PR do?

Standardize conv len function for audio models, uses the following implementation:

```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
```

Fixes #42118

## 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?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?
@eustlb 

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

run-slow: data2vec, hubert, seamless_m4t, seamless_m4t_v2, sew, sew_d, speecht5, unispeech, unispeech_sat, wav2vec2, wav2vec2_bert, wav2vec2_conformer, wavlm
[`Attn Masks`] Non-vmap default for attention masks
Author: vasqu
Pull request: yes

Non-vmap creation of masks. These work with all our base masks and we only default back to vmap when using patterns we cannot guarantee (i.e. additional and/or masks).

Note:
- Non-vmap works with every mask that has anything index based
- Merged old/new sdpa under one function --> easier maintenance imo
- Executorch does not need an additional masking fn anymore
- Lifts some restrictions on older torch versions, e.g. chunked attn with padding, packed attn masks etc

Fixes #41639

cc @jiqing-feng @IlyasMoutawwakil 

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

Hi @vasqu . Anything blocks merge?

> Do you mind expanding a bit more on what are the limitations of the broadcasting approach here for posterity? Is it only index-based operations as you mention on the comments, or are there more subtle things?

Nothing I'm aware of, the only condition is to write the mask_function as a comparison between the indexes (and constants).
One example of this is the bidirectional_mask_function which was written as `q_idx.new_ones((), dtype=torch.bool)` simply returns a scalar 1 (true) and @vasqu rewrote it as `q_idx >= 0` (always true). I think any mask function can be written as f(b, h, q, kv) but I can't prove it 😂

Merging this then! Let's see what crazy masks come up in the future; for now the "mask hypothesis" holds :laughing: 

@jiqing-feng was mainly blocked by me being out last week ;)
Fix GPT-2 Flash Attention 2 generation with left-padding
Author: Abdennacer-Badaoui
Pull request: yes

# What does this PR do?

Fixes Flash Attention 2 generation with left-padding in GPT-2 by ensuring `is_causal=True` is set even when padding masks are provided.

Flash Attention 2 handles causal masking and padding independently, but the original code incorrectly disabled causal masking when any attention mask was present.

Fixes: `test_flash_attn_2_generate_padding_left`

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

@vasqu , ready for review :) 

All the is_causal logic is correctly handled by the integrations; we just need to make sure we define it correctly on init

Makes sense. Thanks @vasqu, @Cyrilvallez. Pushing the changes now.

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

run-slow: decision_transformer, gpt2

run-slow: decision_transformer, gpt2

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

models: ["models/decision_transformer", "models/gpt2"]
quantizations: []

run-slow: decision_transformer, gpt2

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

⚠️ No test being reported (jobs are skipped or cancelled)!


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

models: ["models/decision_transformer", "models/gpt2"]
quantizations: []

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

✅ No failing test specific to this PR 🎉 !


@Abdennacer-Badaoui can you run the fa tests locally and confirm that those work? Seems like our CI doesn't have FA installed anymore so just wanna double check

@vasqu, I tested the FA failing tests for which I opened the PR. they’re all passing.

Thx a lot :heart:
Fix model name test for compressed tensors 
Author: SunMarc
Pull request: yes

# What does this PR do?

As per title, the models that were used to test compressed-tensors changed. Also test_llama_8b_fp8 output depends on the hardware, so I changed it even it passes on h100. 

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

run-slow: compressed_tensors_integration

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42128). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
fix continuous batching issues, extend ut cases to xpu
Author: yao-matrix
Pull request: yes

@SunMarc , pls help review, thx very much.

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

@SunMarc , I think we are OK to go now, thx very much.

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41830). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix MaskFormer/Mask2Former fast image processors
Author: yonigozlan
Pull request: yes

# What does this PR do?

Depends on https://github.com/huggingface/transformers/pull/41391.
These two fast image processors had issues and were not properly tested:
- There was an issue where the processors would crash if `do_resize-False`
- After conversion to binary masks, the grouped masks cannot be stacked anymore, as their channels dimensions are not the same. This fix uses the method introduced in https://github.com/huggingface/transformers/pull/41391 to group the masks according to the shapes of the corresponding images.

This PR fixes the issues and ensure that the integration tests are also ran with the fast image processors

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

Hey @molbap ! This should be ready to merge if you can approve it :)

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

run-slow: mask2former, maskformer
Try refactoring logging to make type checks pass
Author: Rocketknight1
Pull request: yes

Very experimental PR for now where I try to exorcise some of the ancient sins in `utils/logging.py`

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42130). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Remove unused functions in `image_transforms.py`
Author: yaswanth19
Pull request: yes

Delete a unused function and class from image_transforms.py file.

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

run-slow: vitmatte

@yonigozlan for review. Here `_cast_tensor_to_float` func was unused hence removed it

@yonigozlan Updated the PR to now only remove the unused function and class. It's not used anywhere in the transformers codebase a I doubt these would be used in external libs as they seem trivial

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42044). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Add AutoMergeAdapters: Official Utility to Combine Multiple LoRA Adapters into One Unified Model
Author: 3015pavan
Pull request: no
Labels: name: Feature request

### Feature request

Introduce a new built-in class AutoMergeAdapters to the Transformers/PEFT ecosystem that enables users to merge multiple LoRA adapters trained on different domains or datasets into a single model.

This feature simplifies the process of creating multi-domain fine-tuned models for inference and deployment, without manual merging scripts

### Motivation

Today, users can fine-tune models with LoRA adapters easily using PEFT, but they face a major bottleneck when trying to combine more than one adapter.

Current limitations:

Only one LoRA adapter can be merged using merge_and_unload()

Manual merges are error-prone and undocumented

Model config alignment must be handled manually

No built-in CLI or user-friendly API for adapter composition

A high-level API for multi-adapter merging would:

Promote adapter reusability across domains

Simplify deployment of multi-domain, multi-skill models

Reduce code duplication across community projects

### Your contribution

I would like to implement this feature and contribute the following:

Develop the AutoMergeAdapters class under src/transformers/adapters/auto_merge_adapters.py to support merging multiple LoRA adapters with optional weighted combination and compatibility validation.

Extend transformers-cli by adding a new merge-adapters command for CLI-based merging and model export.

Add unit and integration tests in tests/adapters/test_auto_merge_adapters.py to ensure correctness for weighted merges, config mismatches, and adapter integrity.

Provide documentation including a usage guide and a sample notebook under examples/adapters/merge_multiple_adapters.ipynb.

Publish a demo merged model to the Hugging Face Hub for reproducibility and reference.

Open a clean, well-tested PR and iterate based on maintainer feedback.

Happy to start implementation once the approach is approved. Looking forward to guidance if any adjustments are required.

Comments:
Hi maintainers,

Thanks for the update, and great work on getting this implemented.

I had independently built an implementation before noticing the issue was marked as completed. My work includes a working implementation, test coverage, and supporting examples, all ready for submission.

I completely understand the feature is already complete, but if you are open to reviewing improvements, additional tests, documentation, or refactoring, I would be happy to open a pull request for consideration.

Please let me know if you’d like me to submit it, and I can link the PR here.
🌐 [i18n-KO] Translated `video_processor.md` to Korean
Author: chelsseeey
Pull request: yes

# What does this PR do?

Translated the `video_processor.md` file of the documentation to Korean.
Thank you in advance for your review.

Part of https://github.com/huggingface/transformers/issues/20179

## Before reviewing
- [X] Check for missing / redundant translations (번역 누락/중복 검사)
- [X] Grammar Check (맞춤법 검사)
- [X] Review or Add new terms to glossary (용어 확인 및 추가)
- [X] Check Inline TOC (e.g. `[[lowercased-header]]`)
- [X] Check live-preview for gotchas (live-preview로 정상작동 확인)

## Who can review? (Initial)

<!-- 1. 위 체크가 모두 완료된 뒤에만 KREW 팀원들에게 리뷰를 요청하는 아래 주석을 노출해주세요!-->
May you please review this PR?
 @jungnerd, @luckyvickyricky, @chelsseeey, @skwh54, @maximizemaxwell, @D15M4S 

## 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#start-contributing-pull-requests),
      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.
- [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? (Final)

<!-- 2. KREW 팀원들의 리뷰가 끝난 후에 아래 주석을 노출해주세요! -->
<!---transformers, course는 @stevhliu, agent-course는 @sergiopanieg smol-agents는 @albertvillanova입니다!--->
@stevhliu May you please review this PR? 

Comments:
https://github.com/huggingface/transformers/pull/41021 에서 먼저 작업된 것 같습니다! 

> #41021 에서 먼저 작업된 것 같습니다!

앗 저도 그런줄 알았는데 해당 문서는 video_processors.md이고, 
이번 번역은 /main_classes/video_processor.md으로 거의 같은 이름의 다른 문서입니다.!
Translating attention.md to Chinese
Author: wwwbai
Pull request: no
Labels: name: Documentation

name: WIP

Hi!

I have translated attention.md into Chinese and here is my PR #34716 .
I would appreciate it if someone could review and comment on it.Thanks!!







Comments:
Thanks @wwwbai, cc @stevhliu 

Has this issue been resolved?

#34716 has been merged
Support for Megatron
Author: ri938
Pull request: no
Labels: name: Feature request

### Feature request

Allow training of models to use NVidia Megatron.

### Motivation

My training code is all based around huggingface.

however I am currently traning MoE models like Qwen3-30B-A3B which require megatron to train efficiently. Its really like a 10x speedup and so essential.

I am having to switch to ms-swift because of its support for megatron even though I would prefer to continue with Huggingface (because of existing code).

### Your contribution

I wouldn't be able to support this feature implementation in a substantial way.

Comments:
Just out of curiosity, 10x over nanotron?

not tried nanotron

I compared it to FSDP and Deepspeed stage 3

it seems in line with comments and benchmarks others have made as to Megatrons effectiveness on Moe training.
Fix T5Gemma module structure
Author: Cyrilvallez
Pull request: yes

# What does this PR do?

As per the title. We never use direct inheritance from module to module. 

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

run-slow: t5gemma

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

run-slow: t5gemma

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

models: ["models/t5gemma"]
quantizations: []

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

✅ No failing test specific to this PR 🎉 !
'LlavaNextVideoProcessor' has no attribute 'from_dict'.
Author: jiqing-feng
Pull request: no
Labels: name: bug

### System Info

regression PR: #41865 



### Who can help?

@MilkClouds @SunMarc 

### 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
from transformers import LlavaNextVideoProcessor
processor = LlavaNextVideoProcessor.from_pretrained("llava-hf/LLaVA-NeXT-Video-7B-hf")
```

output:
```
AttributeError: type object 'LlavaNextVideoProcessor' has no attribute 'from_dict'. Did you mean: 'to_dict'?
```

Before the regression PR, the processor class is `<class 'transformers.models.llava_next_video.video_processing_llava_next_video.LlavaNextVideoVideoProcessor'>`, after this PR, the processor class is `<class 'transformers.models.llava_next_video.processing_llava_next_video.LlavaNextVideoProcessor'>`

### Expected behavior

Which processor should we use?

The previous check `if video_processor_class_inferred in VIDEO_PROCESSOR_MAPPING_NAMES.values()` should be false and the processor class should be `video_processor_class = VIDEO_PROCESSOR_MAPPING[type(config)]`. Now the check is replaced by `if video_processor_class_from_name(video_processor_class_inferred) is not None` which is True, so the processor class is video_processor_class_inferred. Which one should we use?

Comments:
This issue is relevant inly to LlavaNextVideo which has naming inconsistencies because it uses an image processor from a different model. The PR which caused regression is needed to support remote code so I think the best solution is to fix configs for LlavaNextVideo on the hub and add a `video_processing_config.json`

I will update all configs today-tomorrow. If anyone stumbles upon this issue, I recommend to load and save a `LlavaNextVideoVideoProcessor` to your repo

```python
video_processor = LlavaNextVideoVideoProcessor.from_pretrained(model_id)
video_processor.push_to_hub(model_id)
```

Done! Closing as resolved
Fixes wrong epoch count in trainer under some conditions
Author: i3hz
Pull request: yes

# What does this PR do?
When using an iterable dataset, the Trainer incorrectly calculates `steps_in_epoch` as `max_steps`, 
causing epoch values to be 2x smaller than expected.


Fixes #41913 



## 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?
- [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. https://github.com/huggingface/transformers/issues/41913
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?
@Rocketknight1  @SunMarc @nzw0301 

members/contributors who may be interested in your PR.



Comments:
Mistral Tokenizer Converter Script - Initialization with Pattern Argument
Author: pandora-s-git
Pull request: yes

The current Mistral Tokenizer from Mistral Common to Transformers converter script uses a default regex pattern for the tokenizer, however Mistral models actually require a specific provided pattern.

More context can be found here: https://huggingface.co/mistralai/Mistral-Small-3.1-24B-Instruct-2503/discussions/84 

This PR will aim to fix this issue by intitializing the tokenizer with the correct pattern.

cc @ArthurZucker 

Comments:
@pandora-s-git any chance we can also directly put something like:
```py
if self.pre_tokenizer[0] is incorrect:
   self.pre_tokenizer[0] = pre_tokenizers.Split(pattern=Regex(r"[^\\r\\n\\p{L}\\p{N}]?[\\p{Lu}\\p{Lt}\\p{Lm}\\p{Lo}\\p{M}]*[\\p{Ll}\\p{Lm}\\p{Lo}\\p{M}]+|[^\\r\\n\\p{L}\\p{N}]?[\\p{Lu}\\p{Lt}\\p{Lm}\\p{Lo}\\p{M}]+[\\p{Ll}\\p{Lm}\\p{Lo}\\p{M}]*|\\p{N}| ?[^\\s\\p{L}\\p{N}]+[\\r\\n/]*|\\s*[\\r\\n]+|\\s+(?!\\S)|\\s+"), behavior = "isolated")
   logger.warning("Fix your file ...")
```

directly in the code so that all incorrect tokenizers will be corrected on-the-fly? 🙏 

@patrickvonplaten I dont think would be a good idea to force replace it, since there are finetuned models around that used the old tokenizer - those will be hard to judge if it will be better or worse with the fix - but we could add a warning only potentially ?
DataCollatorForLanguageModeling TypeError
Author: mjaliz
Pull request: no
Labels: name: bug

### System Info

transformers==4.57.1
macos
python 3.12.12

### Who can help?

_No response_

### Information

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

### Tasks

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

### Reproduction

Just instantiate the DataCollatorForLanguageModeling
it would throw an exeption like this

[/usr/local/lib/python3.12/dist-packages/transformers/data/data_collator.py](https://localhost:8080/#) in __post_init__(self)
    872 
    873             if self.mask_replace_prob < 1:
--> 874                 warnings.warn(
    875                     "Random token replacement is not supported with whole word masking.",
    876                     "Setting mask_replace_prob to 1.",

TypeError: category must be a Warning subclass, not 'str'

### Expected behavior

The code must work without any exeption

Comments:
It instantiates without problems for me! Can you paste the exact code you're using?

Ah, I see your PR at #42144! Yes, you're right - the warning on the code path when you try to use token replacement and WWM together was broken, and threw an error instead. I'll close this and merge #42144. Thank you for the PR!