noamaanMulla-03/transformers-issues huggingface dataset:
[Hack] Support config file for `DeepSeek-V3.2`
Author: hnyls2002
Pull request: yes

This is a hack PR to support `DeepseekV32Config` as the key `deepseek_v32` is missing in transformers. Also see #41196 and https://github.com/sgl-project/sglang/issues/11060#issuecomment-3346459440

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

run-slow: auto

cc @arthurzucker for text models

@ArthurZucker Great thanks!!! Can not wait for your PR
Avoid incorrect generations for KV caches containing more than sliding_window tokens
Author: TimFelixBeyer
Pull request: yes

# What does this PR do?

Gemma3 generates incoherent output when manually calling `forward` with an instance of `HybridCache` which contains more than `sliding_window` tokens of content. 

This is because the call to `past_key_values.get_seq_len()` always returns the sequence length as measured by the cache of the very first layer. Because this is a local attention layer, its `sequence_length` never extends beyond `config.sliding_window`. This leads to an incorrect computation of `cache_position` and incoherent generations down the line. 

To fix it you can simply provide the correct `cache_position` manually.
This behavior is impossible to fix without changing `get_seq_len` of `HybridCache`, so I propose to simply raise an informative error message for now. 


## 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?


## Who can review?
 @ArthurZucker

Comments:
Hi 👋, thank you for opening this pull request! The pull request is converted to draft by default. The CI will be paused while the PR is in draft mode. When it is ready for review, please click the `Ready for review` button (at the bottom of the PR page). This will assign reviewers and trigger CI.

cc @gante as well!

This is being fixed more generally in the cache refactor, yes. Thanks for the pointer! I will add a test for it. @TimFelixBeyer do you have a simple test snippet at hand?

I think it is better to wait for the general fix rather than adding a safeguard just for Gemma.

As announced, this was fixed with cache refactors. PR can be closed!

okay, closing
[repo utils] Update `models_to_deprecate.py`
Author: gante
Pull request: yes

# What does this PR do?

Updates the script:
- Fixes hub usage bugs;
- Stop counting downloads after hitting thresholds, to spare the hub from requests;
- Better prints, so it doesn't seem like the script has hung.
- Add support for aliases and folder<>model_tag mapping

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

Just in case: my concern is more about if we might count the same hub repository multiple times due to the fact we use multiple tags ` for model_tag in model_info["tags"`

```
            for model_tag in model_info["tags"]:
                model_list = HubModelLister(tags=model_tag)  # different `model_tag` might give overlapping repositories ..?
```

It's nit, but could be nice to check / fix when we have the bandwidth to avoid this (if my concern is valid)

I could double-count yes, we can fix it in the next iteration :D (imo duplicate model tags are very uncommon)
Use removeprefix and removesuffix
Author: cyyever
Pull request: yes

# What does this PR do?

To simplify code

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

run-slow: auto, chinese_clip, longt5, rag

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

# What does this PR do?

It could be removed in V5.

Comments:
LGTM but cc @gante to confirm before we get rid of it!

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

# What does this PR do?

This PR removes all the checks for safetensors availability as safetensors became a core dep of transformers 2 years ago

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41233). 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, wav2vec2, wav2vec2_conformer
[`FA3`] Fix masking and loading logic in same process
Author: vasqu
Pull request: yes

There are 2 issues that are addressed
1. Fa3 did not use any masking
    - Now registered correctly
    - Tested indirectly in a rewritten parity check between fa2 and fa3 that already exists 
2. Loading logic for anything fa related - kernels, fa2, fa3 - did not work in the same process: Only the first loaded fa variation will be loaded while now it will be the latest.
    - Only forced to reload if an attention type is set to anything fa.

Small benchmark in the parity test also now has a 1.1x speedup (A100) instead of being around 1x (no improvement).

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

# What does this PR do?

Fixes https://github.com/huggingface/transformers/issues/40874, #41073, #41239
Follow-up to https://github.com/huggingface/transformers/pull/40454 and #40903

Fixes how we retrieve sub configs in `t5gemma`, and also subsequent bugs. More details in the diff :)

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

run-slow: gemma3n, t5gemma

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40939). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
fix TrainerIntegrationDeepSpeed UT failures
Author: yao-matrix
Pull request: yes

when run `TrainerIntegrationDeepSpeed` cases like `pytest -rA tests/deepspeed/test_deepspeed.py::TrainerIntegrationDeepSpeed::test_can_resume_training_normal_zero2_bf16_ds_optim_ds_scheduler`, it will fail w/

>         if "optimizer" in config:
>           if args.adafactor:
> E           AttributeError: 'RegressionTrainingArguments' object has no attribute 'adafactor'
> 
> src/transformers/integrations/deepspeed.py:359: AttributeError

Fix it by using `args.optim`

@ydshieh, @SunMarc  pls help review, thx very much.



Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41236). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Don't convert to `safetensors` on the fly if the call is from testing
Author: ydshieh
Pull request: yes

# What does this PR do?

Don't convert to `safetensors` on the fly if the call is from testing

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

Hey @ydshieh! Unless I'm mistaken, the conversion is ever run once: if a PR was already opened by the converter bot, then it will use it instead of re-running conversion. 
So I don't really see the use of this PR? 

Hi ✋ 

A few lines below the change

> not has_file(pretrained_model_name_or_path, safe_weights_name, **has_file_kwargs)

This `has_file` will check the server (if it didn't find it on local cache). If the hub has it, it won't perform the conversion, but the call to the server (to check the existence) is still performed, which is what this PR is to prevent (in order to reduce the traffic).

Also, this existence check (and conversion) is not meant to be run within a test (or a CI environment).

I see - however I don't really like to inject code specific to CI/tests directly in very general loading code like that. Do you mind if we instead check something like `and os.getenv("ALLOW_CONVERSION", "true") == "true"), and set that variable to False on the CI runners/conftest? 😬

YES, your suggestion looks better!

I will use `DISABLE_SAFETENSORS_CONVERSION` however.

(i.e. if nothing specified, it will do what is currently doing, i.e. conversion. Only if specified as `DISABLE_SAFETENSORS_CONVERSION =true` will change the current behavior)

@Cyrilvallez updated, thanks for the suggestion

My brain must be broken this morning ...

Merge as failing test is irrelevant
add peft team members to issue/pr template
Author: ydshieh
Pull request: yes

# What does this PR do?

PEFT go brrrrr

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

# What does this PR do?

Updates the quantization docs to reflect that bitsandbytes now provides official support for CPU, Intel XPU, and Intel Gaudi. See the [v0.48.0 release notes](https://github.com/bitsandbytes-foundation/bitsandbytes/releases/tag/0.48.0) for more information.

Additionally I keep the yellow icon in the quantization overview section for AMD ROCm and add it for Apple Silicon, as these platforms have preliminary support when built from source.

## Before submitting
- [x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [ ] 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?
@SunMarc @MekkCyber @IlyasMoutawwakil


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

great work ! is rocm not part of this release ?

@IlyasMoutawwakil ROCm isn't included in the PyPI wheels yet, but is available to try in our nightly wheels for gfx90a/gfx942/gfx1100. It's likely to be included in a near future release though. I also expect we'll add gfx950 and gfx1200/gfx1201.
Add Hierarchical Reasoning Model
Author: zbloss
Pull request: no
Labels: name: New model

### Model description

The Hierarchical Reasoning Model (HRM) is showing promise in reasoning tasks. I have been working on cleaning up the [original codebase](https://github.com/sapientinc/HRM) and decided I would also integrate it into the Transformers library so a larger audience could benefit from this project.

Below is a snippet from the team's paper which best describes the model.

```abstract
... Inspired by the hierarchical and multi-timescale processing in the human brain, we propose the Hierarchical Reasoning Model (HRM), a novel recurrent architecture that attains significant computational depth while maintaining both training stability and efficiency. 

HRM executes sequential reasoning tasks in a single forward pass without explicit supervision of the intermediate process, through two interdependent recurrent modules: a high-level module responsible for slow, abstract planning, and a low-level module handling rapid, detailed computations. 

With only 27 million parameters, HRM achieves exceptional performance on complex reasoning tasks using only 1000 training samples. The model operates without pre-training or CoT data, yet achieves nearly perfect performance on challenging tasks including complex Sudoku puzzles and optimal path finding in large mazes. 

Furthermore, HRM outperforms much larger models with significantly longer context windows on the Abstraction and Reasoning Corpus (ARC), a key benchmark for measuring artificial general intelligence capabilities. These results underscore HRM’s potential as a transformative advancement toward universal computation and general-purpose reasoning systems.

```

I have a PR ready to close out this issue.

### Open source status

- [x] The model implementation is available
- [x] The model weights are available

### Provide useful links for the implementation

# Authors

- @imoneoi
- @btoo
- @raincchio
- @liamnorm
- @WC-william
- @zbloss - not an original author but I've implemented a refactor to the original codebase.

# Weights

- [sapientinc/HRM-checkpoint-ARC-2](https://huggingface.co/sapientinc/HRM-checkpoint-ARC-2)
- [sapientinc/HRM-checkpoint-sudoku-extreme](https://huggingface.co/sapientinc/HRM-checkpoint-sudoku-extreme)
- [sapientinc/HRM-checkpoint-maze-30x30-hard](https://huggingface.co/sapientinc/HRM-checkpoint-maze-30x30-hard)

# Original Implementation
 
- Code: https://github.com/sapientinc/HRM
- Paper: https://arxiv.org/abs/2506.21734


# Relevant Incoming Changes

- I've got a PR currently open in their repo that improves readability and organizes the code. This may be helpful to read through if it has not been merged into main yet: https://github.com/sapientinc/HRM/pull/89



Comments:
Support automatic conversion from zero checkpoint to universal checkpoint.
Author: zhengchenyu
Pull request: yes

# What does this PR do?

When deepspeed's world_size changes, ds checkpoints need to be converted to universal checkpoints. This PR is used to support automatic conversion.

## Before submitting
- [ ] 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.


Comments:
cc @sunmarc @mekkcyber maybe?

wait https://github.com/deepspeedai/DeepSpeed/pull/7599
feat: Add DINOv3 support to AutoBackbone 
Author: vijayabhaskar-ev
Pull request: yes

# What does this PR do?

This PR implements DINOv3 support for AutoBackbone.

### ✅ What's Implemented:
- **DINOv3ViTConfig**: Complete configuration class with all DINOv3-specific parameters
- **DINOv3ViTModel**: Full model implementation with RoPE embeddings, register tokens, and SwiGLU MLP
- **DINOv3ViTBackbone**: AutoBackbone integration with multi-scale feature extraction
- **AutoBackbone Integration**: Added to MODEL_FOR_BACKBONE_MAPPING_NAMES in modeling_auto.py  
- **Facebook API Compatibility**: `get_intermediate_layers` method matching Facebook Research implementation
- **Multi-scale Features**: Support for object detection and segmentation downstream tasks

Fixes #40323

Comments:
cc @qubvel @NielsRogge 

Sorry but this looks like LLM generated slop, just copying a `get_intermediate_layers` from the original code base isn't enough. Please review manually and code it appropriately to the Transformers principles

@vijayabhaskar-ev, please refer to the latest version of `modeling_dinov2.py`

> Sorry but this looks like LLM generated slop, just copying a `get_intermediate_layers` from the original code base isn't enough. Please review manually and code it appropriately to the Transformers principles

Sure @NielsRogge , let me check modeling_dinov2.py as suggested by @qubvel  and will update the code.

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

run-slow: auto, dinov3_vit

> rsion of `modeling_dinov2.py`

@qubvel Should positional encodings be returned  as a second output (features, pos) like Meta’s BackboneWithPositionEncoding?

> @vijayabhaskar-ev, please refer to the latest version of `modeling_dinov2.py`

@qubvel @NielsRogge  Can you review the latest commit?

cc @merveenoyan cause you are working on a similar PR

 - https://github.com/huggingface/transformers/pull/40651
add more activation kernels, follow up 
Author: MekkCyber
Pull request: yes

# What does this PR do?

Follow up to add more activation kernels to https://github.com/huggingface/transformers/pull/40890

<img width="1918" height="756" alt="image" src="https://github.com/user-attachments/assets/51acd3ae-5328-45bc-8533-9cf275e8a9ab" />




Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40944). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Javanese language code is `jv`, not `jw` if based on ISO 639-1
Author: fahadh4ilyas
Pull request: no

I kept getting error when testing my finetuned voxtral using Javanese language. Then, I realize that language code for Javanese is wrong here. It should be `jv`, not `jw`, based on ISO 639-1.

https://github.com/huggingface/transformers/blob/3fd456b200ba434e567412cc4517309482653f60/src/transformers/models/whisper/tokenization_whisper.py#L185

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.
Unexpected behavior when modifying Linear.forward with device_map="auto" offloading
Author: huangwei021230
Pull request: no

Hi, thanks for maintaining this great library!

I encountered an unexpected behavior when trying to run inference with a 40B model (~83GB) using `transformers` with `device_map="auto"`.

### Setup

- `transformers` version: 4.41.0
- GPU memory: 24GB
- CPU memory: 90GB
- Model size: ~83GB
- Inference config: `batch_size=1`, `sequence_length=10`, `output_token=1`

### Expected behavior

My understanding is that with `device_map="auto"`, the library should offload layers to CPU and move them into GPU memory just-in-time during forward pass (e.g., by registering hooks on linear layers to load/unload weights).

### Actual behavior

To test this, I manually replaced the original `Linear.forward` function with another function of identical functionality (hoping to remove potential hook effects):

```python
def forward(self, input: torch.Tensor) -> torch.Tensor:
    hidden_states = input @ self.weight.T
    if self.bias is None:
        return hidden_states
    return hidden_states + self.bias

def forward_new(self, input: torch.Tensor) -> torch.Tensor:
    hidden_states = input @ self.weight.T
    if self.bias is None:
        return hidden_states
    return hidden_states + self.bias

```

Then I patched the module to use `forward_new` instead of the original `forward`. Surprisingly:

- The model still runs inference correctly.
- Inference speed improved significantly compared to the default.

This confuses me because if hooks are supposed to manage the load/unload process, I would expect overriding `forward` to break the mechanism.

### Question

Could someone clarify:

- How exactly `device_map="auto"` handles offloading and hooks internally?
- Why inference still works (and even runs faster) after overriding `Linear.forward`?
- Is this expected, or might I be unintentionally bypassing part of the intended mechanism?

Thanks in advance for any insights!

Comments:
cc @SunMarc 

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.
Use regex defailed flags
Author: cyyever
Pull request: yes

# What does this PR do?

This PR uses full names of regex flags for better code readability.

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

run-slow: fsmt, nougat

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41264). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix multi-video timestamp bug in Qwen-3-VL and GLM4V
Author: tim120526
Pull request: yes

# What does this PR do?

This PR fixes a timestamp placeholder error that occurs when multiple videos are included in a single text input.
In `Qwen3-VLProcessor,` frames are sampled from videos, and the relative timestamp placeholder `<{curr_time:.1f} seconds>` is constructed for each frame to indicate its corresponding time information. Previously, the code used the index `i` to retrieve the video metadata (`metadata= video_metadata[i]` ), which only worked correctly for a single video input. When multiple videos were provided, the metadata of the first video was incorrectly used to generate timestamp placeholders for all the other videos, resulting in errors.

This PR replaces the index `i` with the correct video index `index` when retrieving metadata, ensuring that each video use the appropriate timestamp placeholders.

Hi [@zach-huggingface](https://github.com/zach-huggingface) [@SunMarc](https://github.com/SunMarc) [@zucchini-nlp](https://github.com/zucchini-nlp), I am just following up on this bug and the proposed fix. It is a one-line change, and I would be happy to assist with any questions or further clarifications to help get it merged.

Thank you very much!


Comments:
Amazing thanks, can you update the modular files for models so that the CI turns green? 

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

run-slow: glm4v, qwen3_vl

> Amazing thanks, can you update the modular files for models so that the CI turns green?

done. 

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