noamaanMulla-03/transformers-issues huggingface dataset:
Improve new failures reporting
Author: ydshieh
Pull request: yes

# What does this PR do?

Clean up the `new_failures` reports, also adding the "trace".

It looks like 

https://huggingface.co/datasets/hf-internal-testing/transformers_daily_ci/blob/main/2026-01-30/runs/1596-21518380210/ci_results_run_models_gpu/new_failures.json

now

```json
{
    "vit": {
        "failures": {
            "multi-gpu": [
                {
                    "line": "tests/models/vit/test_modeling_vit.py::ViTModelTest::test_config",
                    "trace": "(line 223)  assert 1 == 2"
                },
                {
                    "line": "tests/models/vit/test_modeling_vit.py::ViTModelTest::test_foo",
                    "trace": "(line 220)  assert 1 == 3"
                }
            ],
            "single-gpu": [
                {
                    "line": "tests/models/vit/test_modeling_vit.py::ViTModelTest::test_config",
                    "trace": "(line 223)  assert 1 == 2"
                },
                {
                    "line": "tests/models/vit/test_modeling_vit.py::ViTModelTest::test_foo",
                    "trace": "(line 220)  assert 1 == 3"
                }
            ]
        },
        "job_link": {
            "multi": "https://github.com/huggingface/transformers/actions/runs/21518380210/job/62003150802",
            "single": "https://github.com/huggingface/transformers/actions/runs/21518380210/job/62003150793"
        }
    }
}

```

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43628). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix extras on all supported Python versions
Author: tarekziade
Pull request: yes

# What does this PR do?

It makes sure `extras` can be installed on all supported Python versions.

- cleaned up extras (removed natten, tweaked mistral-common etc,)
- adds a supported Python version range (10->14)
- dynamically update the metadata
- run a smoke test in the CI every night to verify `pip install` works on all extras


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

> Very nice idea in general! I assume it's because those lib versions are not compatible with the python version above the conditional? In some cases, would probably make more sense to have the full extra in the conditional, instead of some of the deps!

yes correct, recent Python versions are not well supported yet for all wheels/platform, in some projects


Supersed by @Cyrilvallez work on https://github.com/huggingface/transformers/commit/e46d21afe2aaf942fd9515b2fba1d6f3affd61a6
Don't modify `tied_weight_keys` in-place
Author: zucchini-nlp
Pull request: yes
Labels: name: for patch

# What does this PR do?

As per title, some models add or delete entries in tied weights depending on configuration. If we load two models consecutively with different configs, it fails to tie weights correctly

I am copying it in `__init__` same way as `keep_in_fp32`. We could also simply `copy` the cls attribute in these two models, where in-place modification happens. WDYT?

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

CI is still super flaky :(

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

run-slow: deformable_detr, grounding_dino, mm_grounding_dino

As discussed CI is still flaky, merging as the test that fails is unrelated - can you write something internally in slack
Allow Attention and Experts to be used as standalone modules
Author: Cyrilvallez
Pull request: yes
Labels: name: for patch

# What does this PR do?

As per the title. Also fix a vllm regresion on experts. Allow Experts and Attention module to be used on their own, such as

```py
import torch
from transformers import AutoConfig
from transformers.models.mixtral.modeling_mixtral import MixtralExperts
config = AutoConfig.from_pretrained("mistralai/mixtral-8x7b-v0.1")
experts = MixtralExperts(config)
experts.forward(torch.randn((1, 64, experts.config.hidden_size)))
```

```py
 File "/home/harry/transformers/src/transformers/integrations/moe.py", line 317, in forward
    experts_forward = ALL_EXPERTS_FUNCTIONS[self.config._experts_implementation]
                      ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/harry/transformers/src/transformers/utils/generic.py", line 1070, in __getitem__
    return self._global_mapping[key]
           ~~~~~~~~~~~~~~~~~~~~^^^^^
KeyError: None
```

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

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

run-slow: afmoe, aimv2, albert, align, altclip, apertus, arcee, aria, audio_spectrogram_transformer, audioflamingo3, bamba, bart, bert, bert_generation, bigbird_pegasus, biogpt
Don't modify mappings in tests
Author: Rocketknight1
Pull request: yes

There are some flaky test failures that are very hard to track down. I suspect the modification of core mappings and `importlib.reload()` in `test_voxtral_tokenizer_converts_from_tekken` has some kind of weird race condition or state mutation issue that affects random other tests, but I'm very unsure. This PR is me experimenting to see if the errors become much less frequent if I change the test to stop doing that.

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

run-slow: auto

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43634). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
[`Rope`] Re-Enable remote code
Author: vasqu
Pull request: yes

As per title, draft to show what would be roughly needed

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

run-slow: llama4

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43609). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
[vllm compat] Separate renaming from conversion ops
Author: Cyrilvallez
Pull request: yes
Labels: name: for patch

# What does this PR do?

As per the title. Following specs described by @hmellor for vllm compatibility, no logic change should be required. Only the following small changes to mappings should be enough


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

> but its not always super convenient when you have a lot of renaming

Some day I plan to support `WeightConverter` as well as `WeightRenaming` in vLLM so this won't be a problem. But for now I only have a WIP for `WeightRenaming`
[`Rope`] Revert #43410 and make inheritance implicit again
Author: vasqu
Pull request: yes

As per title, this is mainly due to the fact that we have little control over remote code which could lead to solutions like
- Closes #43609 --> makes the whole mixin behave like a static holder for methods... 
- Modify methods/inherited classes on the fly --> risky and unnatural behavior might be introduced

Imo, this is the best for now without incurring too many risks

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

run-slow: afmoe, apertus, arcee, aria, bamba, bitnet, blt, chameleon, cohere, cohere2, csm, cwm, dbrx, deepseek_v2, deepseek_v3, dia

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

No worries! Glad it's at least after the big release so no patch required, merging since the failing test is unrelated
🚨 Remove deprecated AnnotionFormat
Author: cyyever
Pull request: yes

# What does this PR do?

It is replaced by `AnnotationFormat`.

Comments:
I have no idea what the deprecated class is doing - cc @molbap @yonigozlan can we safely get rid of it?

It's ok to do IMO, but since it's a deprecation let's add :rotating_light: to the PR name! other than that fine to me

@molbap  @Rocketknight1  fixed

@cyyever the CI is doing its thing again, try rebasing and ping me once it's green!

View the CircleCI Test Summary for this PR:

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

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42983). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
ADD THE DATA
Author: rsiya1986-arch
Pull request: no
Labels: name: bug

### System Info

![Image](https://github.com/user-attachments/assets/2111c238-b431-4c00-b542-101db5370c0f)**RAGHAV SHARMA 
# Load model directly
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("cyrilvallez/test_remote_code_dummy_llama", trust_remote_code=True, dtype="auto")
# Use a pipeline as a high-level helper
from transformers import pipeline

pipe = pipeline("text-generation", model="cyrilvallez/test_remote_code_dummy_llama", trust_remote_code=True)
messages = [
    {"role": "user", "content": "Who are you?"},
]
pipe(messages)**# Use a pipeline as a high-level helper
from transformers import pipeline

pipe = pipeline("text-generation", model="cyrilvallez/test_remote_code_dummy_llama", trust_remote_code=True)
messages = [
    {"role": "user", "content": "Who are you?"},
]
 #pipe(messages)/**

### Who can help?

_No response_

### Information

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

### Tasks

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

### Reproduction

# Use a pipeline as a high-level helper
from transformers import pipeline

pipe = pipeline("text-generation", model="cyrilvallez/test_remote_code_dummy_llama", trust_remote_code=True)
messages = [
    {"role": "user", "content": "Who are you?"},
]
pipe(messages)

### Expected behavior

# Use a pipeline as a high-level helper
from transformers import pipeline

pipe = pipeline("text-generation", model="cyrilvallez/test_remote_code_dummy_llama", trust_remote_code=True)
messages = [
    {"role": "user", "content": "Who are you?"},
]
pipe(messages)

Comments:
Fix `process_bad_commit_report.py`: avoid items to appear in `null` author in the report
Author: ydshieh
Pull request: yes

# What does this PR do?

The file `utils/process_bad_commit_report.py` tried to get a team member to ping on slack, including someone merged a PR despite they are not the author of that PR.

However, that part was written before we have PR comment CI. After this is implemented, we might have "merged_by" being `None` (i.e. `null`) for a PR comment CI.

The previous condition (before this PR)

> failed_tests = [x for x in failed_tests if x["author"] == author or x["merged_by"] == author]

gave confusing results: 

https://huggingface.co/datasets/hf-internal-testing/transformers_pr_ci/blob/main/2026-01-31/runs/27920-21546006888/ci_results_run_models_gpu/new_failures_with_bad_commit_grouped_by_authors.json

(where some items with `author`, so not flaky ones, appeared in 2 top level keys with one being `null` - coming from the fact of  `x["merged_by"] being null`).

v.s.

https://huggingface.co/datasets/hf-internal-testing/transformers_pr_ci/blob/main/2026-01-31/runs/27924-21550696166/ci_results_run_models_gpu/new_failures_with_bad_commit_grouped_by_authors.json

This PR fixes this confusing.

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43662). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
[MoE] add clarifying comments to moe integration
Author: MekkCyber
Pull request: yes

# What does this PR do?

Simply adds some shape comments to clarify more the moe forward implementation

Comments:
View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=43439&sha=399f5f

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43439). 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 fix is beginning .... [View the workflow run here](https://github.com/huggingface/transformers/actions/runs/21290858337).
[kernels] Centralize kernels tests
Author: MekkCyber
Pull request: yes

# What does this PR do?

Merges the two kernel tests files into one file, and remove redundant tests

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42819). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Tie zamba weights correctly
Author: zucchini-nlp
Pull request: yes
Labels: name: for patch

# What does this PR do?

as per title

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

run-slow: zamba, zamba2

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

models: ["models/zamba", "models/zamba2"]
quantizations: []

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

✅ No failing test specific to this PR 🎉 !


Yeah, I'd expect the slow tests to trigger tbh but prob they've been failing in `main` for long time. Will think of a fast test to add

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

run-slow: zamba, zamba2
Improve GPT OSS Conversion Script
Author: KyleMylonakisProtopia
Pull request: no
Labels: name: Feature request

### Feature request

The GPT OSS Conversion Script exposes parameters that are not needed or used, has incorrect documentation, and crashes due to a tiktoken bug.

I improved the script and validated it works with GPT-OSS-20B.

### Motivation

The original motivation is from https://github.com/huggingface/accelerate/issues/3882#issuecomment-3647852585 where I would like to use accelerate to load a GPT-OSS-20B model. This does not work out of the box, however this conversion script helps. Unfortunately the script was broken and had incorrect documentation and dangerous arguments.

### Your contribution

https://github.com/huggingface/transformers/pull/42901

Comments:
undo processing test
Author: itazap
Pull request: yes


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

run-slow: qwen3_omni_moe

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

Fixes from this PR were incorporated into #43537!
`test_apply_chat_template_video_frame_sampling` fails with `num_frames` and `fps` are mutually exclusive
Author: tarekziade
Pull request: no
Labels: name: bug

### System Info

================================================================================= short test summary info =================================================================================
FAILED tests/models/qwen3_vl/test_processing_qwen3_vl.py::Qwen3VLProcessorTest::test_apply_chat_template_video_frame_sampling - ValueError: `num_frames` and `fps` are mutually exclusive arguments, please use only one!

### Reproduction

pytest -sv tests/models/qwen3_vl/test_processing_qwen3_vl.py::Qwen3VLProcessorTest::test_apply_chat_template_video_frame_sampling

### Expected behavior

passing test

### Why it happens

1. The test passes fps=None explicitly to signal "don't use fps, use num_frames instead"
2. The current code filters out None values at processing_utils.py:1728, so fps=None doesn't get added to mm_load_kwargs
3. The video processor has a default fps=2 in its configuration
4. When fps is not explicitly passed to the video processor, it falls back to self.fps=2 (see video_processing_utils.py:263)
5. Both num_frames=3 and fps=2 end up being non-None, triggering the mutual exclusivity check

We can explicitely set kwargs to None in processing_utils.py but I don't like that fix I find it fragile.

@ArthurZucker WDYT

Comments:
This is a rather old branch in the PR. We've refactored and moved video loading into each model's own `video_processor` class, and passing an explicit `fps=None` should work. The video processor will not set a default value if `fps` is already present in input kwargs

oops, yes, sorry for the noise! it passes in `main`
[`Sam`] Fixup training flags
Author: vasqu
Pull request: yes

Kind of a follow up to #43556 which fixed a bunch of wrong inheritance with gradient ckpting. Just dummy exchanged the proper flags and I didn't have to skip a lot of these tests

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43567). 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: edgetam, sam, sam2, sam3, sam3_tracker, sam_hq
[`HunYuan`] Fix RoPE init
Author: vasqu
Pull request: yes

As per title, currently init weights assumes everything is uniform but these dynamic inits are slightly different

Comments:
cc @xenova if you could check if it works for you, just made a quick draft for this as we talked internally about this models series

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

run-slow: hunyuan_v1_dense, hunyuan_v1_moe

💔 This comment contains `run-slow`, but unknown error occurred and [the workflow run](https://github.com/huggingface/transformers/actions/runs/21283405723) aborted!

run-slow: hunyuan_v1_dense, hunyuan_v1_moe

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

models: ["models/hunyuan_v1_dense", "models/hunyuan_v1_moe"]
quantizations: []

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

✅ No failing test specific to this PR 🎉 !


run-slow: hunyuan_v1_moe

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

run-slow: hunyuan_v1_dense, hunyuan_v1_moe

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

models: ["models/hunyuan_v1_moe"]
quantizations: []

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

✅ No failing test specific to this PR 🎉 !
Use correct sampling rate in chat template
Author: zucchini-nlp
Pull request: yes

# What does this PR do?

Fixes https://github.com/huggingface/transformers/issues/43262

Supersedes https://github.com/huggingface/transformers/pull/43273 and https://github.com/huggingface/transformers/pull/43660

I don't think the prev PR will be updated by contributor, since it's a code agent PR. Also I am seeing that it attracts more code agents as long as the issue is open, so let's merge a fix here

I also made a small clean-up of `ChatTemplateKwargs` and deleted unused/duplicate kwargs, as we discussed in above linked PR review comments

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

> Is there any related test that can be checked?

yeah, the processor MixinTests have a `test_chat_template_audio` which is passing in audio LLMs
fix(processing): use feature_extractor.sampling_rate as default in apply_chat_template
Author: theonlypal
Pull request: yes
Labels: name: Code agent slop

## Summary

- Use processor's `feature_extractor.sampling_rate` as default when loading audio in `apply_chat_template()`
- Fall back to 16kHz only when no feature_extractor is available

## Problem

`apply_chat_template()` hardcoded 16kHz as the default sampling rate, ignoring the processor's configured value. This caused audio to be incorrectly resampled (e.g., 24kHz audio resampled to 16kHz for CsmProcessor).

## Fix

1. Changed `ChatTemplateLoadKwargs.sampling_rate` default from `16_000` to `None`
2. Added runtime resolution using `self.feature_extractor.sampling_rate` when available

Fixes #43262

Comments:
View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=43273&sha=ad4f73
Fix audio processors defaulting to 16kHz in apply_chat_template
Author: jonathan-fulton
Pull request: yes
Labels: name: Code agent slop

## What does this PR do?

Fixes #43262

### Problem

The `apply_chat_template()` method always defaults to 16kHz sampling rate, even when the processor's feature extractor specifies a different rate:

```python
processor = AutoProcessor.from_pretrained('sesame/csm-1b')
print(processor.feature_extractor.sampling_rate)  # 24000

batch = processor.apply_chat_template(
    chat_messages,
    return_dict=True,
    return_tensors='pt',
    tokenize=True,
)
print(batch['input_values'].shape)  # Shape indicates 16000 samples (wrong!)

# Workaround: explicitly pass sampling_rate
batch = processor.apply_chat_template(
    chat_messages,
    sampling_rate=processor.feature_extractor.sampling_rate,  # Have to manually specify!
    ...
)
```

### Root Cause

The default sampling rate (16000) is hardcoded in `ChatTemplateLoadKwargs`:

```python
class ChatTemplateLoadKwargs(TypedDict, total=False):
    sampling_rate: int | None = 16_000  # Hardcoded default
    ...
```

This default is used regardless of what the processor's feature extractor actually expects.

### Solution

After setting up `mm_load_kwargs`, check if:
1. The user didn't explicitly provide `sampling_rate` in kwargs
2. The processor has a `feature_extractor` with a `sampling_rate` attribute

If both conditions are met, use the feature extractor's sampling rate as the default:

```python
if 'sampling_rate' not in kwargs:
    processor_sampling_rate = getattr(getattr(self, 'feature_extractor', None), 'sampling_rate', None)
    if processor_sampling_rate is not None:
        mm_load_kwargs['sampling_rate'] = processor_sampling_rate
```

This is backwards compatible:
- Users who explicitly pass `sampling_rate` still get their specified value
- Processors without a `feature_extractor` or without a `sampling_rate` attribute fall back to 16kHz
- Processors with proper audio support now automatically use the correct sampling rate

## Who can review?

@ArthurZucker @itazap

Comments:
hey thanks for the PR! It would be great to add a simple test for this case 🙏 

It was fixed on `main` btw, sorry. The first PR by contributor got stale so we fixed it in #43674