noamaanMulla-03/transformers-issues huggingface dataset:
[Fix] Bug when loading audio data from an URI
Author: remi-or
Pull request: yes

This PR fixes a bug when calling `load_audio_torchcoded` or `load_audio_librosa` on data formatted as an URI. 

Currently, when running `tests/cli/test_serve.py::TestMultimodalLM::test_chat_completion_with_audio` (among 4 failing tests) the `load_audio_...` function crashes because it is passed data as an URI, formatted like this:
```
data_uri = f"data:audio/{codec};base64,{data_in_base64}"
```
and the `load_audio_...` does not handle that case. So the function returns a string while a numpy array is expected. This function adds an `elif` branch for that case and fixes this test.
I ran only `test_serve.py` and saw the 4 failing tests disappear.

BTW, the fail was happening with `load_audio_torchcoded` and `load_audio_librosa`, but I noticed a similar pattern in `load_audio_as` so I extended the pattern to that one, although I saw no test failing with it. LMK if that needs a rollback!

cc. @eustlb for audio side and @SunMarc for serve

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

**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46673)

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=46673&sha=685741
ci: disable CircleCI by replacing config with no-op
Author: ydshieh
Pull request: yes

## What does this PR do?

Replaces the full CircleCI config with a minimal no-op job that immediately passes, and disables the CircleCI failure summary workflow.

**Why not just delete the config?** Removing `config.yml` causes CircleCI to post a failing "no configuration found" check. Replacing it with a no-op keeps the check green while doing nothing.

**Changes:**
- `.circleci/config.yml` — replaced with a single no-op job (`echo` only, completes in seconds)
- `.github/workflows/circleci-failure-summary-comment.yml` → `.bak` — disables the workflow that posted CircleCI failure summaries as PR comments

To restore CircleCI: revert `config.yml` to its previous content and rename the workflow file back.

Comments:
**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46721)

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46721). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
feat: bump safetensors to `0.8.0`
Author: McPatate
Pull request: yes

cf [release notes](https://github.com/safetensors/safetensors/releases/tag/v0.8.0) for more deets


general idea: fast mps load thanks to loading weights via native `MTLBuffer`s and handing them off to torch via dlpack (0-copy!) -> 2-3x perf on my setup for loading models when torch>=2.9 + fixes duplicate memory footprint causing OOMs.

Comments:
**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46523)

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

Luc said he'll do doc soon!
[docs] clarify initialization module usage
Author: stevhliu
Pull request: yes

adds docs for using the `transformers.initialization` module and updates the `Wav2Vec2ForPreTraining` code snippet which uses `reset_parameters` now

Comments:
**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46698)

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46698). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
[`Kernels`] Add new kernels to models: CE, Swiglu, Geglu(, Linear)
Author: vasqu
Pull request: yes

As per title, branched out from #46039 to propogate the actual kernels so we can use them on models. Since the dep tree is a bit more complicated and we should sync sooner than later, we move this to a separate PR

## Currently to be applied
The core changes are currently in
- Llama
    - Swiglu MLP
    - CE
- Gemma2 
    - Geglu MLP
    - CE

## Potential other kernel
We could also add kernels around torch native `nn.Linear` applying tiled forwards/backwards similar to their fused couterparts (e.g. Tiled Swiglu MLP). That would only be enabled during trainin making a simple wrapper/patcher like
```
@use_kernel_forward_from_hub("Linear")
class Linear(nn.Linear):
    pass

nn.Linear = Linear
```

## Benchmark
Using Llama with this [script](https://gist.github.com/vasqu/644694c190e16e76f1d5536f8037d001)
<img width="3000" height="1800" alt="image" src="https://github.com/user-attachments/assets/89dd254d-2408-43df-b77a-d88e6a3aac0f" />

Comments:
View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=46575&sha=648cc9

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

run-slow: gemma2, llama

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46575). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Add some AITER kernel routing for ROCm
Author: Abdennacer-Badaoui
Pull request: yes

Routes ROCm to AITER Triton kernels on AMD GPUs:
  - `flash_attention_3` → [`kernels-community/aiter-flash-attn`](https://huggingface.co/kernels-community/aiter-flash-attn)
  - `megablocks` → [`kernels-community/megablocks`](https://huggingface.co/kernels/kernels-community/megablocks) now has rocm builds.
  
  - `rotary_pos_emb` → [`kernels-community/aiter-rope`](https://huggingface.co/kernels-community/aiter-rope)

Longer-term goal: ship the full AITER in Kernels (same model as `liger-kernels`) rather than one repo per kernel. We're starting with `aiter-rope` and `aiter-flash-attn` because those are the two we need in transformers right now.

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

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=46268&sha=5ba56a

@Abdennacer-Badaoui time to sync with main. Can you readjust? Then I would merge afterwards :saluting_face: 

Yes, I’m done. If you don't have any additional comments or concerns, we can merge it.

Nope looks good, adding it to the queue
Fix beam cache reordering for non-default cache keys
Author: yinli-systems
Pull request: yes

## Summary

Beam search only reordered `past_key_values`, so models that keep generation state under another supported cache key could skip cache reordering during beam updates.

This patch resolves the active cache through `ALL_CACHE_NAMES` and reorders whichever cache key is actually populated. It keeps the model-specific `_reorder_cache` path for models such as XLNet/RAG, and otherwise calls `reorder_cache()` on cache objects.

Fixes #46612.

## Validation

- `python3 -m py_compile src/transformers/generation/utils.py tests/generation/test_utils.py`
- `PYTHONPATH=src /Users/yinxiaogou/Documents/resume/.venvs/transformers-test/bin/python -m pytest -q tests/generation/test_utils.py -k "beam_search_reorders_non_default_cache_key or beam_search_uses_model_reorder_for_non_default_cache_key"`

The test venv only added the missing main-branch test dependencies needed locally (`huggingface-hub>=1.5`, `safetensors>=0.8`, `pytest-xdist`, `parameterized`).

Comments:
**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46735)
[RecurrentGemma] Support attn_implementation dispatch
Author: YangKai0616
Pull request: yes

# What does this PR do?

As per the title.

Comments:
On my local A100, the `run_slow` tests `output_text` from this PR are identical to `upstream/main` (note: `upstream/main` has 4 failed, 1 passed. `IntegrationTest` issues will not be addressed in this PR for now.).

@vasqu 

All comments have been addressed.

Friendly ping @vasqu 👀.

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

run-slow: recurrent_gemma

run-slow: recurrent_gemma

[Workflow Run ⚙️](https://github.com/huggingface/transformers/actions/runs/27712924567)

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

models: ["models/recurrent_gemma"]
quantizations: []

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

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

### Commit Info
| Context | Commit | Description |
|---------|--------|-------------|
| RUN | [df8faefc](https://github.com/huggingface/transformers/commit/df8faefce575d16ca518e3776db47b4af2236a09) | workflow commit (merge commit) |
| PR | [bd2ee023](https://github.com/YangKai0616/transformers/commit/bd2ee02377a41994c529fc63a335a64f8a734542) | branch commit (from PR) |
| main | [497d83c5](https://github.com/huggingface/transformers/commit/497d83c56a2970e8e505789e9988014e4ca3d8ee) | base commit (on `main`) |

✅ No failing test specific to this PR 🎉 👏 !
skip decorators must appear after @parameterized.expand in pytest
Author: rasmi
Pull request: yes

# What does this PR do?

In pytest v8.4+, skip decorators must be applied to the function being tested, which isn't the case if unittest.skip wraps `parameterized.expand`.

## Code Agent Policy

- [X] I confirm that this is not a pure code agent PR.

## 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://huggingface.co/docs/transformers/contributing) and the
      [Pull Request](https://huggingface.co/docs/transformers/pr_checks) checks?
- [ ] 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 according to the [guidelines](https://github.com/huggingface/transformers/tree/main/docs)?
- [ ] Did you write any new necessary [tests](https://huggingface.co/docs/transformers/testing)?


## Who can review?

@zucchini-nlp FYI!


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

run-slow: minicpmv4_6

**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46737)

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46737). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
GlmMoeDsa: head_dim→qk_rope_head_dim attribute_map silently clobbers the rope head dim (GLM-5.2)
Author: Kasempiternal
Pull request: no

### System Info

- `transformers` 5.8.1
- Model: GLM-5.2 (`model_type: glm_moe_dsa`, `GlmMoeDsaForCausalLM`)

### Description

`GlmMoeDsaConfig` declares `attribute_map = {"head_dim": "qk_rope_head_dim"}`, so `head_dim` is an
alias for `qk_rope_head_dim`. But GLM-5.2's released `config.json` sets **both** fields with
**different** values (`"head_dim": 192`, `"qk_rope_head_dim": 64`). Because of the alias, `head_dim`
(192, which equals `qk_nope_head_dim`) silently **overwrites** the real `qk_rope_head_dim` (64).

### Reproduction

```python
from transformers.models.glm_moe_dsa.configuration_glm_moe_dsa import GlmMoeDsaConfig

c = GlmMoeDsaConfig(head_dim=192, qk_rope_head_dim=64, qk_nope_head_dim=192, kv_lora_rank=512)
print(c.qk_rope_head_dim)   # -> 192   (expected 64)
print(GlmMoeDsaConfig.attribute_map)
# {'num_local_experts': 'n_routed_experts', 'head_dim': 'qk_rope_head_dim'}
```

Loading the released GLM-5.2 `config.json` (which contains both keys) reproduces the same:
`config.qk_rope_head_dim == 192`.

### Why this is a bug

The checkpoint geometry pins `qk_rope_head_dim = 64`, not 192:
- `kv_a_proj_with_mqa.weight` is `[576, 6144]` → `576 = kv_lora_rank(512) + qk_rope_head_dim(64)`.
- `q_b_proj.weight` is `[16384, 6144→]` → `16384 / 64 heads = 256 = qk_nope_head_dim(192) + qk_rope_head_dim(64)`.

With `qk_rope_head_dim` clobbered to 192, the MLA head is computed as `512 + 192 = 704` instead of
`512 + 64 = 576`, which breaks MLA weight loading in downstream runtimes (e.g. vLLM raises a
`narrow(... 704) exceeds dimension size (576)` during `fused_qkv_a_proj` load). `head_dim` is also
ambiguous for an MLA attention head whose q/k/v sub-dims differ, so aliasing it onto the rope dim
is surprising.

### Suggested fix

Drop the `"head_dim": "qk_rope_head_dim"` entry from `GlmMoeDsaConfig.attribute_map` (and/or remove
the redundant `head_dim` from the released `config.json` so the explicit `qk_rope_head_dim` stands).
Happy to open a PR if that's the preferred direction.

### Expected behavior

`config.qk_rope_head_dim` should be 64 (its explicit value and the checkpoint-true rope dim), not be
overwritten by `head_dim`.


Comments:
"Hi! I'd love to take this on and remove the head_dim entry from the attribute map as suggested. Could you assign this to me?"

Update — this is already resolved on `main`: #46338 (2026-06-02) dropped the `head_dim → qk_rope_head_dim` entry from `attribute_map`, and `GlmMoeDsaConfig.__post_init__` now sets `self.head_dim = self.qk_rope_head_dim` explicitly, so `qk_rope_head_dim` is no longer clobbered (confirmed against current `main`). I'd filed this against a pinned 5.8.1; it only affects releases predating #46338, where `--hf-overrides '{"qk_rope_head_dim": 64}'` is the runtime workaround. Closing as already-fixed — thanks!
Reflect baked post-processor in `add_bos_token`/`add_eos_token`
Author: ArthurZucker
Pull request: yes

Fast tokenizers with a `TemplateProcessing` baked into `tokenizer.json` left `add_bos_token`/`add_eos_token` as `False` despite the post-processor adding bos/eos. Now inferred from the post-processor without rebuilding it. Test added.

cc @itazap

Comments:
**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46722)

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46722). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
AutoProcessor reports “Unrecognized image processor” when required vision backend is missing
Author: sisaman
Pull request: no
Labels: name: bug

### System Info

Observed with `transformers==5.12.1` in an environment with `torch` installed but `torchvision` missing.

### Who can help?

_No response_

### Information

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

### Tasks

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

  AutoProcessor.from_pretrained("HuggingFaceTB/SmolVLM-256M-Instruct")
```

In an environment where torchvision is **not** installed, this can fail with:
```
ValueError: Unrecognized image processor in HuggingFaceTB/SmolVLM-256M-Instruct...
```
This is misleading because the model/config can be recognized; the real issue is that the image processor implementation is unavailable due to a missing optional dependency. Installing `torchvision` makes the same processor load successfully.

This does not affect every vision processor equally. Some models can fall back to a PIL-based image processor when `torchvision` is unavailable and Pillow is installed. The issue is specifically that when no usable mapped backend implementation can be imported, the auto processor path should surface a dependency/backend error instead of an “unrecognized image processor” error.

### Expected behavior

The error should explain that no mapped image processor backend class could be loaded and suggest installing the missing backend dependency, rather than implying that the image processor or model type is unrecognized.

Comments:
Going to the linked PR, will comment there if anything
[docs] metal flash attention
Author: stevhliu
Pull request: yes

adds docs for #45974 (install `kernels` to automatically use the metal flash kernel on MPS with `transformers serve`)

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46349). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix Swin2SR padding for aligned images
Author: nightcityblade
Pull request: yes
Labels: name: Code agent slop

# What does this PR do?

Fixes #46697.

This updates the Swin2SR slow and fast image processors to compute padding with modulo arithmetic, so images whose height/width are already divisible by `size_divisor` are not padded by an extra full divisor. It also updates the test helpers and adds a regression test for an aligned image.

## 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. #46697
- [ ] 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?

@yonigozlan @molbap


Comments:
[DO NOT REVIEW] test `huggingface_hub` 1.20.0.rc0
Author: hanouticelina
Pull request: yes

**Note** : this PR is meant only to trigger the CI against  the pre-release of `huggingface_hub`

Comments:
Thank you for your contribution 🤗!

## CI Security Gate — automatic approval blocked

This PR was **not** automatically approved for CI because the security gate failed.

**Possible reasons:**
- The PR touches 50 or more files — only PRs with fewer than 50 changed files are automatically approved
- A changed file is outside the allowed directories (`src/`, `tests/`, `docs/`, `utils/`), has a disallowed extension (only `.py`, `.txt`, `.md` permitted outside `tests/` and `docs/`), or is not `.md`/`.yml` inside `docs/`
- A new high-severity security issue was detected in the changed Python files (Bandit check)

See the [workflow run](https://github.com/huggingface/transformers/actions/runs/27762272611) for the exact violations.

A maintainer can review and manually approve CI if a finding is a false positive.

**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46745)

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

All good!
ci: trigger PR CI on ci-* branches
Author: ydshieh
Pull request: yes

## Summary
- Extend `push` trigger in `pr-ci-caller.yml` to include `ci-*` branch name pattern alongside `main`


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

# What does this PR do?

This PR adds support for HF Buckets in Trainer. Instead of storing checkpoints locally or on the hub repository, we can leverage HF Buckets for that (S3 like storage + XET dedup). 

With buckets (`push_to_buckets=True`), users don't need to save the checkpoints on the hub anymore like before (hub_strategy="checkpoint" or "all_checkpoints") as we push all checkpoints to the bucket. Still, pushing to the hub is still useful (hub_strategy="every_save") as it will upload a version of a model that can we load with transformers. 

Features:
- Saving checkpoints to HF Buckets
- Resuming training from HF Buckets

Right now, everything should be pretty much compatible like before since we are just synching a local dir to the HF Buckets async but in the future, it would be a lot better if  we are able load / save directly from / to HF Buckets without going through the disk, might be useful for deepspeed and fsdp.  


## Usage

```python 
from transformers import Trainer, TrainingArguments

trainer = Trainer(
    model=model,
    args=TrainingArguments(
        output_dir="out",
        save_strategy="steps",
        push_to_bucket=True,
        bucket_id="bucket_id",
    ),
    train_dataset=train_dataset,
)
trainer.train()

# resume on a fresh machine — pulls the latest checkpoint from the bucket
trainer.train(resume_from_checkpoint="hf://buckets/my-org/my-run")
```

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

**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46386)
fix: update validation logic for fast image processor registration
Author: MelkiZedekICT
Pull request: yes
Labels: name: Code agent slop

## Contribution Summary — Hugging Face Transformers Bug Fix

Successfully identified and resolved a critical issue in the `huggingface/transformers` repository where valid fast image processors were mistakenly classified as slow processors, leading to unexpected application crashes.

### Key Contributions

* **Issue Investigation & Debugging:** Created an isolated reproduction script to trace the problem to incorrect inheritance validation inside `AutoImageProcessor.register`.

* **Core Fix Implementation:** Refactored the registration logic to explicitly validate against `BaseImageProcessorFast`, eliminating false-positive detections.

* **Regression Protection:** Added comprehensive unit tests covering both valid registrations and intentionally incorrect configurations to prevent future regressions.

* **Open-Source Best Practices:** Followed community contribution standards by working within a local virtual environment, running required linters, using conventional commit messages, and providing terminal verification in the Pull Request.

### Impact

The fix restores reliable registration behavior for fast image processors, prevents runtime crashes, and improves overall maintainability and safety for downstream users and integrators of the Transformers ecosystem.


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

run-slow: auto

**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46733)