noamaanMulla-03/transformers-issues huggingface dataset:
fix error vocab_size at Qwen2_5_VLForConditionalGeneration loss_function
Author: killight98
Pull request: yes

# What does this PR do?

<!--
Congratulations! You've made it this far! You're not quite done yet though.

Once merged, your PR is going to appear in the release notes with the title you set, so make sure it's a great title that fully reflects the extent of your awesome contribution.

Then, please replace this with a description of the change and which issue is fixed (if applicable). Please also include relevant motivation and context. List any dependencies (if any) that are required for this change.

Once you're done, someone will review your PR shortly (see the section "Who can review?" below to tag some potential reviewers). They may suggest changes to make the code even better. If no one reviewed your PR after a week has passed, don't hesitate to post a new comment @-mentioning the same persons---sometimes notifications get lost.
-->

<!-- Remove if not applicable -->

Based on changes at PR #37033, `vocab_size` should be obtained from `self.config.text_config`, not `self.config` at Qwen2_5_VLForConditionalGeneration loss_function calling.


Comments:
cc @zucchini-nlp

> Thanks, can you check other multimodal models as well if they use a `text_config`, and then run `make fix-copies` to pass the CI check

@zucchini-nlp thanks for u response.
after checking other multimodal models, i found `qwen2_vl` has similar issue and fixed it at latest comment.

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

run-slow: qwen2_5_vl, qwen2_vl

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

@bot /style

Style bot fixed some files and pushed the changes.
[SAM 2] Change checkpoints in docs and tests
Author: yonigozlan
Pull request: yes

# What does this PR do?

As the title says, change checkpoints to the official facebook ones.
Feel free to merge without me as I'll be off, Cc @ArthurZucker @Cyrilvallez @ydshieh.

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

run-slow: sam2, sam2_video

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40213). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
add-loftr-keypoints-to-map
Author: alexdzm
Pull request: yes

# What does this PR do?
The[ official demo for eloftr](https://huggingface.co/zju-community/matchanything_eloftr) does not work with the current transformers because `EfficientLoFTRForKeypointMatching` is not instantiated when the model is called. This fixes the problem by adding it to the model mapping.


## 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?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

@qubvel tagging you as you reviewed the pr that added this model



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

run-slow: auto

Thanks for the issue! That's the problem of the code snippet, rather than `transformers` code, we should use `AutoModelForKeypointMatching` instead of `AutoModel`. I've fixed the snippet, let me know if that helps
Make dataclasses dependency conditional for python<3.7
Author: badwriter123
Pull request: yes

### Summary ###

This PR updates the dataclasses dependency to only be installed for Python versions less than 3.7, since dataclasses became part of the Python standard library starting with Python 3.7.

### Changes ###
1. Modified setup.py to add python_version<'3.7' marker to the dataclasses dependency.
2. Updated dependency_versions_table.py via make deps_table_update.

### Why This Change ###
1. The dataclasses package is only needed as a backport for Python < 3.7
2. For Python 3.7+, the built-in dataclasses module should be used instead.
3. This reduces unnecessary dependencies for modern Python versions.
4. The project already requires Python >= 3.9.0, so this dependency is currently redundant for all supported versions.

Before : "dataclasses",

After : "dataclasses;python_version<'3.7'",



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

run-slow: gemma3n

Noted 👍

Thanks for understanding (and still for your PR, appreciate the thought!) :hugs: I'll close this then
The 'dataclasses' dependency should be marked for python<3.7
Author: yurivict
Pull request: no
Labels: name: bug

### System Info

Currently this dependency is unconditional.
See https://pypi.org/project/dataclasses/

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

n/a

### Expected behavior

n/a

Comments:
Please see my comments [here](https://github.com/huggingface/transformers/pull/40228#pullrequestreview-3128002220)

We don't support python 3.8 and below, so if you were to opt for lower versions, you are on your own. I'll close this.
MT5ForConditionalGeneration no longer importable after torch and transformers upgrade
Author: MarcoDiMarek
Pull request: no
Labels: name: bug

### System Info

ModuleNotFoundError: Could not import module 'MT5ForConditionalGeneration'. Are this object's requirements defined correctly?

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

from transformers import MT5ForConditionalGeneration

Name: transformers
Version: 4.55.2

Name: torch
Version: 2.8.0

Platform tested: Windows

### Expected behavior

Import of the module that has existed for years....

Comments:
Note, downgrading torch to 2.6.0 fixed it. I had just upgraded it to the latest version because transformers threw an error when loading models regarding the unsafety of torch.load.

Sorry, did not mean to close the issue. Just add a comment.
Question: How to write a custome tokenizer form scratch
Author: obadx
Pull request: no

In this guide you introduced how to write a custom model and custom model configuration: [here](https://huggingface.co/docs/transformers/main/en/custom_models), IN addition I want to create a custom tokenizer form scratch why ?

I have a problem of multilevel transcription: the model takes an input utterance and output a 12 multilingual transcript simultaneously . So I want to design a tokenzier such that it take the whole 12 languages as a dict: 

```python
{
    "lang1": "text text",
    "lang2": "text text", 
    "lang3": "text text",
}
```

and after tokenization


```python
{
    "input_ids": 
    {
        "lang1": "ids of lang 1",
        "lang2": "ids of lang 2",
        "lang3": "ids of lang 2",
    }
}
```


How to do so as I can not find docs of building such custom tkenizer from scratch ?

Comments:
Might [this](https://huggingface.co/learn/llm-course/en/chapter6/8#building-a-wordpiece-tokenizer-from-scratch) be what you are looking for?

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.
🚨 [V5] Remove deprecated training arguments 
Author: cyyever
Pull request: yes

# What does this PR do?
 
Remove deprecated training arguments from `TrainingArguments`

Comments:
cc @SunMarc 

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

@Rocketknight1 And this one:)
Support loading LFM2 GGUF
Author: HaroldBenoit
Pull request: yes

# What does this PR do?

Currently, GGUF versions of LFM2 models raises "GGUF model with architecture lfm2 is not supported yet" error. This PR resolves this issue.

## 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).
- [x] Did you write any new necessary tests?


 @SunMarc @MekkCyber

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

run-slow: ggml

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

# What does this PR do?

Add TimesFM 2.5 model

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40879). 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, timesfm_2p5
[torchao safetensors] integrate torchao safetensors support with transformers 
Author: liangel-02
Pull request: yes

**Context**

Currently, we need to use `safe_serialization=False` while saving models as shown [here](https://huggingface.co/pytorch/Qwen3-8B-INT4#quantization-recipe). This PR enables safetensors support for torchao so that users can now save and load checkpoints using safetensors. Currently, only Float8Tensor is supported (`Float8DynamicActivationFloat8WeightConfig`, `Float8WeightOnlyConfig`) but allowing other subclasses should involve minimal code changes.

```
# default forsafe_serialization is True
quantized_model.push_to_hub(save_to)
```

**Summary**

Changes to transformers code includes: 

1.  In ```TorchAoHfQuantizer```, we provide ```get_state_dict``` and ```update_state_dict_with_metadata``` that flattens/unflattens a model state dict with tensor subclasses by calling functionality built out in [this PR](https://github.com/pytorch/ao/pull/2881). 
2. In ```modeling_utils.py```, we make appropriate changes to support propagating the metadata from tensor subclasses. We also add logic similar to `hqq` and `bnb` to directly load onto `cpu` rather than `meta`.

**Test Plan**

Modified unit test to allow safe serialization. Run using ```python tests/quantization/torchao_integration/test_torchao.py```

Reference https://huggingface.co/torchao-testing/opt-125m-Float8WeightOnlyConfig-v2-0.14.0.dev-safetensors for an example of a serialized model and test script


Comments:
cc @mekkcyber for quantization

looks good, please update PR summary to align with recent code changes as well

cc @SunMarc @MekkCyber please check if the API changes make sense

Would be very nice to have this propagated to `diffusers` as well :) 

@SunMarc @MekkCyber do you guys mind taking another look? thanks!

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

run-slow: torchao_integration

@SunMarc can you please merge?

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

Hey @liangel-02 @jerryzh168! I refactored how quantizers should integrate with the loading in https://github.com/huggingface/transformers/pull/41138! Since the safetensors serialization from this PR is not out yet in torchao, I could not easily test it and make sure everything is nice. Please, have a look, especially [here](https://github.com/huggingface/transformers/blob/main/src/transformers/quantizers/quantizer_torchao.py#L116-L120) 🙏
Qwen3-next feature dims are mismatched in torch_chunk_gated_delta_rule
Author: jyC23333
Pull request: no

@Cyrilvallez @bozheng-hit 
Hello, when I'm running the inference code of Qwen3-next during reviewing the `modeling_qwen3_next.py` file, I found the dimension is confused when the `hidden_states` are passed to the `torch_chunk_gated_delta_rule` function of `Qwen3NextGatedDeltaNet` class.

Please refer the code here: https://github.com/huggingface/transformers/blob/main/src/transformers/models/qwen3_next/modeling_qwen3_next.py#L461

My input query is `Give me a short introduction to large language model`, the same as the official example.

In this function, the shape of the input `key` is `[1， 18， 32， 128]`. Obviously this shape is `[(batch_size, seq_len, num_heads, head_k_dim)]`.

Then the feature are processed by this:
```
    query, key, value, beta, g = [
        x.transpose(1, 2).contiguous().to(torch.float32) for x in (query, key, value, beta, g)
    ]
```
and the shape of `key` will be `[1， 32， 18， 128]`, 

However, the next line of the code is:
```
    batch_size, sequence_length, num_heads, k_head_dim = key.shape
``` 

It seems that there is a mismatch in the code.

Thanks.

Comments:
I think this maybe a type error or mismatch since the `recurrent_state` variable later should be static per batch. However it is decalred as `last_recurrent_state = torch.zeros(batch_size, sequence_length, k_head_dim, v_head_dim)` which appears to increase based on the length of the input sequence.

Additionally, the `num_heads` variable represents the sequence length, but its name suggests it refers to the number of attention heads.

When I manually changed the code from ` batch_size, sequence_length, num_heads, k_head_dim = key.shape` to ` batch_size, num_heads, sequence_length, k_head_dim = key.shape`, an error will occured.

So this part of code is really confused, because the `num_heads` variable is used several times later.

Maybe the original intention was to split chunk from the `num_heads` dimension, but the final implementation was to split chunk from the `seq_len` dimension.

Don't know whether it has any effect.

I have editted this file in https://github.com/hebangwen/transformers/commit/85fa2017b817e07eb25de0291200f5fd340467a5 , which just swaps the `num_heads` and `sequence_length` variable.  However I cannot validate this code without enough GPU. Perhaps you can have a try.

Hey there

#41036 changes this to follow the correct namings. It seems like `seq_len` and `num_heads` were confused as you pointed out. It's not changing the logic but more so makes the naming more coherent again.

Indeed there was a mismatch in variables names! Thanks for flagging!
[Qwen3-next] Fix dimension mismatch in torch_chunk_gated_delta_rule and torch_recurrent_gated_delta_rule (#40963)
Author: notkisk
Pull request: yes

## Fixes #40963 

## Issue
When running inference with **Qwen3-next** (`modeling_qwen3_next.py`), a dimension mismatch occurs in the `Qwen3NextGatedDeltaNet` class inside the `torch_chunk_gated_delta_rule` function.

- Input tensors start as `(batch_size, seq_len, num_heads, head_dim)`.
- After `transpose(1, 2)`, the shape becomes `(batch_size, num_heads, seq_len, head_dim)`.
- The code incorrectly unpacks as `(batch_size, sequence_length, num_heads, k_head_dim)`, causing inconsistent calculations and runtime errors.

See [line 461](https://github.com/huggingface/transformers/blob/main/src/transformers/models/qwen3_next/modeling_qwen3_next.py#L461).

## Solution
Updated both `torch_chunk_gated_delta_rule` and `torch_recurrent_gated_delta_rule` in **`modular_qwen3_next.py`**:

- Corrected dimension unpacking:
  ```python
  batch_size, num_heads, sequence_length, k_head_dim = key.shape

##Verification

- Reproduced the bug and confirmed the mismatch.

- Applied the fix and re-ran tests: 96 passed, 134 skipped (all as expected).

- Verified inference works correctly on the official example query:
“Give me a short introduction to large language model.”

##Root Cause

The bug was caused by assuming the original dimension order after transpose(1, 2).
This led to wrong unpacking of key.shape, which then broke padding, chunking, and recurrent state initialization.
The fix ensures consistent handling of dimensions after the transpose operation.

Comments:
cc @arthurzucker for text models maybe?

run-slow: qwen3_next

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

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

@vasqu @Rocketknight1 push to production🤞

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

run-slow: qwen3_next

run-slow: qwen3_next

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

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

Thanks a lot @notkisk, merging after docs have been built :hugs: 

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41036). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix the error where a keyword argument appearing before *args
Author: cyyever
Pull request: yes

# What does this PR do?

While it is valid, this is confusing and it may cause subtle bugs.

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41099). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix broken `` expressions in markdown files
Author: cyyever
Pull request: yes

# What does this PR do?

As the title says.

## 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?
- [ ] 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?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

<!-- Your PR will be replied to more quickly if you can figure out the right person to tag with @

 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.

Models:

- text models: @ArthurZucker
- vision models: @amyeroberts, @qubvel
- speech models: @eustlb
- graph models: @clefourrier

Library:

- flax: @gante and @Rocketknight1
- generate: @zucchini-nlp (visual-language models) or @gante (all others)
- pipelines: @Rocketknight1
- tensorflow: @gante and @Rocketknight1
- tokenizers: @ArthurZucker
- trainer: @zach-huggingface, @SunMarc and @qgallouedec
- chat templates: @Rocketknight1

Integrations:

- deepspeed: HF Trainer/Accelerate: @SunMarc @zach-huggingface
- ray/raytune: @richardliaw, @amogkam
- Big Model Inference: @SunMarc
- quantization (bitsandbytes, autogpt): @SunMarc @MekkCyber

Documentation: @stevhliu

HF projects:

- accelerate: [different repo](https://github.com/huggingface/accelerate)
- datasets: [different repo](https://github.com/huggingface/datasets)
- diffusers: [different repo](https://github.com/huggingface/diffusers)
- rust tokenizers: [different repo](https://github.com/huggingface/tokenizers)

Maintained examples (not research project or legacy):

- Flax: @Rocketknight1
- PyTorch: See Models above and tag the person corresponding to the modality of the example.
- TensorFlow: @Rocketknight1

 -->


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

# What does this PR do?

Most of them are copy and paste bugs..


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

run-slow: big_bird, colpali, colqwen2, csm, cvt, d_fine, deberta_v2, depth_pro, dpt, esm, evolla, hubert, kosmos2_5, levit, llava_next, llava_next_video

@Rocketknight1 Fixed

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41062). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
wrong metadata of widht and height when read video use read_video_torchvision
Author: Juude
Pull request: no
Labels: name: bug

name: Vision

### System Info

the bug still exist in master branch 

### Reproduction

1. infer video vlm like smolvlm-video-256m
2. if using torchvision to decode video, will run in to function `read_video_torchvision`
3. attach debugger and you will notice that the height is always 3

### Expected behavior

the height variable should be video's height

Comments: