PULL REQUEST #45960: chore: update circleci-failure-summary-comment.yml
State: closed  |  Merged: False
Author: hf-security-analysis[bot]  |  Base: main
Labels:
Created: 2026-05-14T06:11:41Z

Update `.github/workflows/circleci-failure-summary-comment.yml` workflow configuration.

cc @XciD @ArthurZucker

Closes huggingface/tracking-issues#465
<!--slack ts:1778739102.831539 channel:C0AJSP0D53L-->

--- Comment by HuggingFaceDocBuilderDev at 2026-05-14T06:24:17Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45960). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

--- Comment by XciD at 2026-05-14T07:13:15Z ---
cosmetic


PULL REQUEST #45959: chore: update build-ci-docker-images.yml
State: closed  |  Merged: True
Author: hf-security-analysis[bot]  |  Base: main
Labels:
Created: 2026-05-14T06:11:11Z

Update `.github/workflows/build-ci-docker-images.yml` workflow configuration.

cc @XciD @ArthurZucker

Closes huggingface/tracking-issues#464
<!--slack ts:1778739073.188339 channel:C0AJSP0D53L-->

--- Comment by HuggingFaceDocBuilderDev at 2026-05-14T06:23:02Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45959). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


chore: update assign-reviewers.yml

PULL REQUEST #45958: chore: update assign-reviewers.yml
State: closed  |  Merged: False
Author: hf-security-analysis[bot]  |  Base: main
Labels:
Created: 2026-05-14T06:10:34Z

Update `.github/workflows/assign-reviewers.yml` workflow configuration.

cc @XciD @ArthurZucker

Closes huggingface/tracking-issues#463
<!--slack ts:1778739035.975189 channel:C0AJSP0D53L-->

--- Comment by HuggingFaceDocBuilderDev at 2026-05-14T06:21:20Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45958). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

--- Comment by XciD at 2026-05-14T07:06:19Z ---
already safe by default, cosmetic


chore: update anti-slop.yml

PULL REQUEST #45957: chore: update anti-slop.yml
State: closed  |  Merged: False
Author: hf-security-analysis[bot]  |  Base: main
Labels:
Created: 2026-05-14T06:10:14Z

Update `.github/workflows/anti-slop.yml` workflow configuration.

cc @XciD @ArthurZucker

Closes huggingface/tracking-issues#462
<!--slack ts:1778739016.414539 channel:C0AJSP0D53L-->

--- Comment by HuggingFaceDocBuilderDev at 2026-05-14T06:21:23Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45957). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

--- Comment by XciD at 2026-05-14T07:12:58Z ---
break the feature


PULL REQUEST #45956: fix(ci): remove template injection on pull_request_target workflows
State: closed  |  Merged: True
Author: XciD  |  Base: main
Labels:
Created: 2026-05-14T06:02:49Z

## Summary

Eliminate every `error[template-injection]` finding in `.github/workflows/` by routing PR-author / matrix / input-derived values through `env:` instead of GitHub Actions `${{ ... }}` rendering directly into shell or `actions/github-script` JS source.

Zizmor 1.24.1: **22 `error[template-injection]` → 0**.

## Files touched

### `pull_request_target` / `issue_comment` (highest exposure)
- **`pr_slow_ci_suggestion.yml`** (`pull_request_target`)
  - `PR_FILES` was placed inside a `<< 'EOF'` heredoc in `run:`. The single-quoted heredoc only stops shell expansion *after* GitHub renders `${{ ... }}`; a filename containing `EOF\n<payload>\nEOF` would escape the heredoc and run on the runner. Now `env: { PR_FILES: ... }` + `printf '%s\n' "$PR_FILES"`.
  - `PR_HEAD_REPO_OWNER`, `PR_HEAD_REPO_NAME`, `PR_HEAD_SHA`, `PR_NUMBER` were interpolated directly into `actions/github-script` script bodies; moved to `env:` + `process.env`.
- **`pr-repo-consistency-bot.yml`** (`issue_comment`, gated by maintainer allowlist)
  - Quoted every `${PR_HEAD_REF}`, `${PR_HEAD_SHA}`, `${PR_HEAD_REPO_FULL_NAME}` shell expansion in `git fetch`, `git checkout`, `git remote add`, `git push`.
  - Final `Comment on PR` step now passes `comment_id` and `final_comment` via `env:` (no `${{ ... }}` left in the script body).
- **`trl-ci-bot.yml`** (`issue_comment`, gated by `author_association`)
  - `github.event.issue.pull_request.url` passed via env. GitHub-controlled value, but principle is the same.

### Reusable workflows (callable from PR comment CI)
- **`get-pr-info.yml`**: `inputs.pr_number` passed via env, shared between two API calls.
- **`check_failed_tests.yml`**: `pr_number` + `commit_sha` passed via env in the Extract base commit step.

### Reusable workflows (callable from scheduled / dispatched CI)
- **`collated-reports.yml`**: `machine_type`, `job`, `report_repo_id`, `gpu_name` exposed as env, quoted in the python invocation.
- **`model_jobs_intel_gaudi.yml`**: `inputs.folder_slices`, `inputs.machine_type`, `inputs.report_name_prefix`, `matrix.folders` pulled into `env:`; report-directory name built once and reused.
- **`self-scheduled-flash-attn-caller.yml`**: `prev_workflow_run_id` / `other_workflow_run_id` passed via env before being written to disk.
- **`self-scheduled-intel-gaudi.yml`**: `inputs.job` passed via env; `NUM_SLICES` dereferenced via env in the `python3 -c` snippet.

## Validation

- Zizmor 1.24.1: 22 `error[template-injection]` → 0 across the whole `.github/workflows/` tree.
- `node --check` on every `actions/github-script` `script:` body touched: ✅
- `bash -n` on every `run:` block touched: ✅
- Behavior preserved: the same values reach the same code paths, only the wiring changed (templating → env vars).

## Out of scope (will be follow-up PRs)

- Bumping `actions/github-script@v6` → `@v7` (handled by the pin-by-SHA PR #45955).
- `pr-repo-consistency-bot.yml:7` invalid `branches-ignore` filter on `issue_comment` (pre-existing).
- Replacing the hardcoded maintainer allowlist with a team-membership check.
- Switching `secrets: inherit` to explicit per-secret passing in the 17 callers.

--- Comment by ArthurZucker at 2026-05-14T06:08:02Z ---
@bot /style

--- Comment by github-actions[bot] at 2026-05-14T06:08:48Z ---
Style fix fix runs successfully without any file modified.

--- Comment by HuggingFaceDocBuilderDev at 2026-05-14T06:17:32Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45956). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


PULL REQUEST #45955: chore(ci): pin all GitHub Actions and reusable workflows by SHA
State: closed  |  Merged: True
Author: XciD  |  Base: main
Labels:
Created: 2026-05-14T05:53:53Z

## Summary

Replace mutable tag/branch references with commit SHAs across `.github/workflows/`. Mitigates the `tj-actions/changed-files` class of supply-chain attack: if a third-party action repo is compromised (account takeover, force-push to tag), the workflow keeps running the audited commit.

- Ran `pinact run` on `.github/workflows/`, which resolved every `actions/*@v<X>` to `@<40-char-sha> # v<X.Y.Z>`.
- Manually pinned the few cross-repo `workflow_call` / composite-action refs that `pinact` does not handle:
  - `huggingface/hf-workflows/...@main` (3 AMD CI callers, 1 docker-images workflow)
  - `huggingface/doc-builder/.github/workflows/build_pr_documentation.yml@main`
  - `huggingface/transformers-test-ci/.../pr-ci_dynamic_caller_example.yml@main`
- Zizmor 1.24.1: 129 `error[unpinned-uses]` -> 0.

No behavior change: each SHA is the current HEAD of the referenced tag/branch at commit time, so jobs run exactly the same code as before. Follow-up: a `dependabot.yml` config (separate PR) will keep these pins current with automated PRs.

## Reviewer notes

- Diff is large but uniform; the safe way to review is to skim that every `@v<X>` was replaced by `@<sha> # v<X.Y.Z>`.
- Workflows still consuming `git+https://github.com/huggingface/accelerate@main#egg=accelerate` in `pip install` are intentional (testing against bleeding-edge accelerate) and were left as-is.
- pinact also normalized some pre-existing version-comment suffixes (e.g. `# v4` -> `# v4.6.2`) when the resolved tag pointed at a more specific release.

--- Comment by HuggingFaceDocBuilderDev at 2026-05-14T06:06:43Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45955). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


PULL REQUEST #45954: tests: fix duplicated "for" in test_video_utils FIXME comment
State: closed  |  Merged: False
Author: otjdiepluong  |  Base: main
Labels:
Created: 2026-05-14T03:52:29Z

Tiny docs/comment fix: remove the duplicated "for" in a FIXME comment in `tests/utils/test_video_utils.py`. No code/behavior change.

--- Comment by Rocketknight1 at 2026-05-14T14:16:25Z ---
Hey, we prefer to avoid these small style fixes right now. We're still getting a lot of agent PRs and we're trying to preserve maintainer attention for important fixes. We'll do a big style pass with a code agent at some point to catch all these small typos


PULL REQUEST #45953: Strip language_model. prefix when loading multimodal Gemma 4 checkpoint into Gemma4ForCausalLM
State: closed  |  Merged: False
Author: huzama  |  Base: main
Labels:
Created: 2026-05-14T02:06:51Z

## What does this PR do?

Adds the `gemma4_text` entry to `_build_checkpoint_conversion_mapping` —
one line, adjacent to the existing analogue for `qwen3_5_text`:

```python
"gemma4_text": [PrefixChange(prefix_to_remove="language_model", model_prefix="model")],
"qwen3_5_text": [PrefixChange(prefix_to_remove="language_model", model_prefix="model")],
```

On-disk, `google/gemma-4-E4B-it` is a `Gemma4ForConditionalGeneration`
checkpoint with the language model under `model.language_model.*`.
`AutoModelForCausalLM.from_pretrained(...)` dispatches to the multimodal
class — keys align natively and it works correctly. The broken path is
the text-only class itself: anyone calling
`Gemma4ForCausalLM.from_pretrained("google/gemma-4-E4B-it")` directly
(e.g. fine-tuning / retrofit that doesn't need the vision + audio
towers) gets a silent prefix mismatch — every `model.layers.{0..41}.*`,
`embed_tokens`, `lm_head` is MISSING; every
`model.language_model.layers.*` is UNEXPECTED; the model initialises
from random weights with only a
`tied weights mapping … both are absent from the checkpoint` warning.

Reproducer (pure HF, no other deps):

```python
import torch
from transformers import AutoConfig
from transformers.models.gemma4.modeling_gemma4 import Gemma4ForCausalLM

cfg = AutoConfig.from_pretrained("google/gemma-4-E4B-it").get_text_config()
m = Gemma4ForCausalLM.from_pretrained("google/gemma-4-E4B-it", config=cfg, dtype=torch.bfloat16)
w = m.model.layers[0].self_attn.q_proj.weight.detach().float()
print(w.mean(), w.std())   # ≈ (-4e-6, 0.0199) — HF default Gaussian init, not Gemma weights
```

After the patch the same reproducer shows trained-weight statistics and
the missing-keys list is empty. The entry is keyed on
`model_type == "gemma4_text"` and is a strict no-op for every other
model type — no existing checkpoint loads differently.

## Before submitting

- [x] I confirm that this is not a pure code agent PR.
- [ ] 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/)?
- [x] Did you make sure to update the documentation with your changes? — N/A, internal weight-conversion mapping.
- [x] Did you write any new necessary tests? — The mirrored `qwen3_5_text` entry has no dedicated unit test either; happy to add one if reviewers prefer.

## Who can review?

@Cyrilvallez (model loading / `from_pretrained`)

--- Comment by Rocketknight1 at 2026-05-14T14:19:46Z ---
LGTM but will wait for Cyril to confirm

--- Comment by Cyrilvallez at 2026-05-15T04:48:34Z ---
Hey @huzama! We don't really want to maintain such cases, as they add quite a bit of complexity and headaches in mappings... Since google decided to map the AutoModelForCausalLM to the ConditionalGeneration model, the preferred way to only get the text model would then be:

```python
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("google/gemma-4-E4B-it").model.language_model
```

Hope this helps! Let me know if not! Closing this in the meantime!


PULL REQUEST #45952: hf_argparser: fix parse_yaml_file missing utf-8 encoding and wrong docstring
State: closed  |  Merged: False
Author: Dev-X25874  |  Base: main
Labels: Code agent slop
Created: 2026-05-14T01:21:22Z

# What does this PR do?

Fixes two small issues in `parse_yaml_file` that were introduced as copy-paste errors from `parse_json_file`.

**Bug 1 — Missing `encoding="utf-8"` (line 425)**

`parse_json_file` explicitly opens files with `encoding="utf-8"`:
```python
with open(Path(json_file), encoding="utf-8") as open_json_file:
```
But `parse_yaml_file` uses `Path.read_text()` without specifying encoding:
```python
yaml.safe_load(Path(yaml_file).read_text())
```
On Windows, `read_text()` defaults to the system locale encoding (e.g. `cp1252`), not utf-8. YAML files containing non-ASCII characters will silently corrupt or raise a `UnicodeDecodeError` on non-utf-8 systems. The fix adds `encoding="utf-8"` to match `parse_json_file`.

**Bug 2 — Wrong word in docstring (line 417)**

The `allow_extra_keys` description says `"the json file contains keys"` — a copy-paste error from `parse_json_file`. Changed to `"the yaml file"`.

- [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://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?
- [ ] Did you make sure to update the documentation with your changes?
- [ ] Did you write any new necessary tests?

## Who can review?
@ArthurZucker

--- Comment by github-actions[bot] at 2026-05-14T01:21:33Z ---
This PR was flagged by our automated quality checks. If you're a genuine
contributor, please reply here and a maintainer will review your PR.

Common reasons for flagging:
- New GitHub account
- Unusually high number of repository forks in a 24-hour window

We appreciate your contribution and apologize if this is a false positive!

--- Comment by Dev-X25874 at 2026-05-15T04:54:25Z ---
Hi @Rocketknight1, sorry I missed checking the "I confirm this is not a pure code agent PR" checkbox earlier. I'm a genuine contributor — this is a real copy-paste bug where parse_yaml_file is missing encoding="utf-8" unlike parse_json_file which has it explicitly. Could you take a look and reopen if you think it's worth merging? Happy to make any changes needed.


[docs] new attention mask helpers

PULL REQUEST #45949: [docs] new attention mask helpers
State: closed  |  Merged: True
Author: stevhliu  |  Base: main
Labels:
Created: 2026-05-13T17:40:26Z

adds docs for #43924 on using new `create_*_mask` functions

--- Comment by HuggingFaceDocBuilderDev at 2026-05-13T17:52:21Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45949). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

--- Comment by vasqu at 2026-05-13T18:43:27Z ---
We should have a warning here that these and/or masks are powerful to express any pattern but in turn are slower - this can be noticable on slower models especially (e.g. 200M) - and are not compatible with executorch

--- Comment by vasqu at 2026-05-13T18:45:34Z ---
I would not reference gemma here but just keep it as general example --> how to turn causal to bidirectional etc

I need to refactor this because it's not so efficient 😬

--- Comment by vasqu at 2026-05-13T18:46:51Z ---
not sure but maybe we could reorder to have the same order as in the base attention interface -> how to build?

--- Comment by vasqu at 2026-05-13T18:47:34Z ---
FA needs a base 2D padding mask


PULL REQUEST #45948: fix feature extractor error messages to mention processor_config.json
State: closed  |  Merged: False
Author: lianakoleva  |  Base: main
Labels:
Created: 2026-05-13T17:04:37Z

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

This PR gives a more accurate error message to users who may run into an error in `get_feature_extractor_dict`. The code fails when neither `FEATURE_EXTRACTOR_NAME (preprocessor_config.json)` nor `PROCESSOR_NAME (processor_config.json)` are present, so both should be mentioned as possibly missing in the error message.

## Code Agent Policy

The Transformers repo is currently being overwhelmed by a large number of PRs and issue comments written by
code agents. We are currently bottlenecked by our ability to review and respond to them. As a result,
**we ask that new users do not submit pure code agent PRs** at this time.
You may use code agents in drafting or to help you diagnose issues. We'd also ask autonomous "OpenClaw"-like agents
not to open any PRs or issues for the moment.

PRs that appear to be fully agent-written will probably be closed without review, and we may block users who do this
repeatedly or maliciously.

This is a rapidly-evolving situation that's causing significant shockwaves in the open-source community. As a result,
this policy is likely to be updated regularly in the near future. For more information, please read [`CONTRIBUTING.md`](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md).

- [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).
- [ ] 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.

@zucchini-nlp @molbap

<!-- 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 @Cyrilvallez
- vision models: @yonigozlan @molbap
- audio models: @eustlb @ebezzam @vasqu
- multimodal models: @zucchini-nlp
- graph models: @clefourrier

Library:

- generate: @zucchini-nlp (visual-language models) or @gante (all others)
- continuous batching: @remi-or @ArthurZucker @McPatate
- pipelines: @Rocketknight1
- tokenizers: @ArthurZucker and @itazap
- trainer: @SunMarc
- attention: @vasqu @ArthurZucker @CyrilVallez
- model loading (from pretrained, etc): @CyrilVallez
- distributed: @3outeille @ArthurZucker
- CIs: @ydshieh

Integrations:

- ray/raytune: @richardliaw, @amogkam
- Big Model Inference: @SunMarc
- quantization: @SunMarc
- kernels: @drbh
- peft: @BenjaminBossan @githubnemo

Devices/Backends:

- AMD ROCm: @ivarflakstad
- Intel XPU: @IlyasMoutawwakil
- Ascend NPU: @ivarflakstad

Documentation: @stevhliu

Research projects are not maintained and should be taken as is.

 -->

--- Comment by Rocketknight1 at 2026-05-14T14:13:53Z ---
Hey, we're not being very consistent about it, but we prefer to avoid these very small docstring/typo PRs right now! They add maintainer workload to review and we'll probably just do a big quality pass with code agents at some point


[docs] chat template prefill

PULL REQUEST #45947: [docs] chat template prefill
State: closed  |  Merged: True
Author: stevhliu  |  Base: main
Labels:
Created: 2026-05-13T16:24:22Z

adds docs for #45896 to support custom fields like `reasoning_content`

--- Comment by HuggingFaceDocBuilderDev at 2026-05-13T16:36:04Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45947). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


PULL REQUEST #45946: RFDetr - use correct Roboflow org for release
State: closed  |  Merged: True
Author: sbucaille  |  Base: main
Labels:
Created: 2026-05-13T15:16:59Z

# What does this PR do?

Fix RFDetr checkpoints in docs to point to correct [Roboflow organization](https://huggingface.co/Roboflow)
Also added https://github.com/huggingface/transformers/pull/45829 slight changes from @omkar-334

- [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://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.
- [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).
- [ ] Did you write any new necessary tests?

## Who can review?

@yonigozlan @molbap

--- Comment by vasqu at 2026-05-15T17:37:27Z ---
run-slow: rf_detr

--- Comment by github-actions[bot] at 2026-05-15T17:38:48Z ---
[Workflow Run ⚙](https://github.com/huggingface/transformers/actions/runs/25932228381)

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

models: ["models/rf_detr"]
quantizations: []

--- Comment by github-actions[bot] at 2026-05-15T17:53:10Z ---
## CI Results
[Workflow Run ⚙](https://github.com/huggingface/transformers/actions/runs/25932228381)

### Commit Info
| Context | Commit | Description |
|---------|--------|-------------|
| RUN | [534532d7](https://github.com/huggingface/transformers/commit/534532d73708ec60750cd44f6393ed70f98ca36f) | workflow commit (merge commit) |
| PR | [bb68576a](https://github.com/sbucaille/transformers/commit/bb68576af885f62936657a6371932ccc9fb6c851) | branch commit (from PR) |
| main | [331f1007](https://github.com/huggingface/transformers/commit/331f1007c381426aba57687b1ff9845f46b9de02) | base commit (on `main`) |

✅ No failing test specific to this PR 🎉 👏 !

--- Comment by sbucaille at 2026-05-15T18:04:26Z ---
@vasqu done !

--- Comment by github-actions[bot] at 2026-05-15T18:04:58Z ---
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: rf_detr

--- Comment by vasqu at 2026-05-15T18:05:43Z ---
Thank you! @sbucaille merging now

--- Comment by HuggingFaceDocBuilderDev at 2026-05-15T18:17:09Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45946). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


PULL REQUEST #45945: Fix OLMo 3 scaled RoPE handling for sliding attention
State: open  |  Merged: False
Author: nurpax  |  Base: main
Labels:
Created: 2026-05-13T14:56:30Z

## Summary

- Restores OLMo 3 per-layer rotary embeddings after the [RoPE layer-type refactor](https://github.com/huggingface/transformers/pull/39847/files#diff-036fcee5ab04376314d213c74252019c66043aa88b7b65d9c5e55e0b8e90265cL302).
- Uses default, unscaled RoPE for `sliding_attention` layers and configured RoPE for `full_attention` layers.
- Keeps the current `Gemma2RotaryEmbedding` forward behavior, including returning `cos.to(dtype=x.dtype), sin.to(dtype=x.dtype)`.
- Adds a unit test that catches the regression with a mixed sliding/full attention config and YARN RoPE.

## Context

`Olmo3Model` documents that RoPE scaling is not applied to sliding-window attention layers, but the current implementation computes one configured rotary embedding and passes it to every layer. OLMo 3 needs layer-type-specific RoPE: default RoPE for sliding attention and configured/scaled RoPE for full attention.

## Test plan

- `PYTHONPATH=src python utils/check_modular_conversion.py --files src/transformers/models/olmo3/modular_olmo3.py --num_workers 1`
- `ruff check src/transformers/models/olmo3/modular_olmo3.py src/transformers/models/olmo3/modeling_olmo3.py tests/models/olmo3/test_modeling_olmo3.py`
- `git diff --check`
- `PYTHONPATH=src pytest tests/models/olmo3/test_modeling_olmo3.py -k sliding_attention_uses_default_rope_with_scaled_config -q`

AI assistance was used to prepare this PR. I reviewed the generated diff and am responsible for the change.

--- Comment by github-actions[bot] at 2026-05-13T18:55:07Z ---
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: olmo3, olmo_hybrid


PULL REQUEST #45944: [pp_formulanet] Fix polynomial ReDoS in remove_chinese_text_wrapping
State: closed  |  Merged: False
Author: LinZiyuu  |  Base: main
Labels: Code agent slop
Created: 2026-05-13T14:52:41Z

## Summary

Fixes a polynomial ReDoS in `PPFormulaNetProcessor.remove_chinese_text_wrapping`.

Reported via huntr: https://huntr.com/bounties/72f2cbf7-60af-4c21-89ba-1265f7ba2088

The pattern compiled in PPFormulaNetProcessor.__init__:

    re.compile(r"\\text\s*{([^{}]*[一-鿿]+[^{}]*)}")

has overlapping greedy `[^{}]*` quantifiers around an inner CJK class. `[一-鿿]` is a strict subset of `[^{}]`, so a run of CJK characters can be re-partitioned by the engine in O(N^2) ways. When the closing `}` is missing the engine then walks the tail O(N) times before failing each split, giving O(N^3) total work. A ~10 KB `\text{` + CJK input pins one CPU core for ~50 seconds.

The vulnerable method is reachable from public API: `PPFormulaNetProcessor.post_process_generation(text: str)` and `remove_chinese_text_wrapping(formula: str)` both accept attacker-supplied strings, and a truncated `generate(..., max_new_tokens=K)` that stops inside a `\text{...}` block feeds the same shape into the post-processor with no attacker required.

Fix: drop the inner CJK class from the regex and enforce the CJK predicate in the Python replacer. The body is now `[^{}]*`, a single quantified class the engine cannot re-partition; matching is linear in input length. Semantics are preserved -- the wrapping is still only stripped when the body contains at least one CJK ideograph and no nested braces.

Verified on a 12800-char unclosed-brace CJK payload: 0.12 ms patched vs. tens of seconds unpatched, plus equivalence on closed/empty/ nested-brace/whitespace/mixed inputs against the previous regex.

--- Comment by github-actions[bot] at 2026-05-13T14:54:12Z ---
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: pp_formulanet

--- Comment by LinZiyuu at 2026-05-14T15:08:21Z ---
Hi, I noticed the "Code agent slop" label. If I rework the PR without AI, would it be welcome — or do you prefer to  handle the fix internally given the huntr report?

--- Comment by LinZiyuu at 2026-05-15T13:11:43Z ---
Thanks for the response, but I think this was triaged as a conversion-script issue — the report is about runtime processor code, not a conversion script.

Files: `src/transformers/models/pp_formulanet/processing_pp_formulanet.py` and `modular_pp_formulanet.py`. These ship in release builds and are reached through the documented public API `PPFormulaNetProcessor.post_process_generation(text)` → `remove_chinese_text_wrapping`. No pickle loading, no `convert_*.py`.

Could you clarify what distinguishes this report from these two recently fixed ones?

- [CVE-2025-6638](https://www.cve.org/CVERecord?id=CVE-2025-6638) — ReDoS in `tokenization_marian.py::remove_language_code`
- [CVE-2025-6051](https://www.cve.org/CVERecord?id=CVE-2025-6051) — ReDoS in `clvp/number_normalizer.py`, fixed in [#38844](https://github.com/huggingface/transformers/pull/38844) using possessive quantifiers — the same fix pattern proposed as Option 2 in this report

Both are runtime, text-in, public-API ReDoS on tokenizer/processor files, reachable from standard inference pipelines — the same shape as this report. If there is a material difference I'm missing, I'd like to understand it so I can calibrate future reports.


PULL REQUEST #45943: fix: restore `_attn_implementation `and fix request offset in `generate_batch()`
State: closed  |  Merged: True
Author: sergiopaniego  |  Base: main
Labels:
Created: 2026-05-13T13:58:21Z

# What does this PR do?

I'm testing a possible integration of continuous batching in TRL and found a couple bugs that appear only in a training scenario (in `generate_batch()`)

**Bug 1:** `ContinuousBatchingManager.__init__` sets `config._attn_implementation` to `"paged|X"` and never restores it. The next training forward pass crashes. Fix: save before `init_continuous_batching()`, restore in `finally`.

**Bug 2:** `_request_counter` is not reset between `generate_batch()` calls. The second call assigns `req_N..req_{2N-1}` but the reorder loop looks up `req_0..req_{N-1}` → silent data loss / `KeyError`. Fix: capture `start_idx = manager._request_counter` before `add_requests()` and offset the lookup.

Fixes # (issue)

## Code Agent Policy

The Transformers repo is currently being overwhelmed by a large number of PRs and issue comments written by
code agents. We are currently bottlenecked by our ability to review and respond to them. As a result,
**we ask that new users do not submit pure code agent PRs** at this time.
You may use code agents in drafting or to help you diagnose issues. We'd also ask autonomous "OpenClaw"-like agents
not to open any PRs or issues for the moment.

PRs that appear to be fully agent-written will probably be closed without review, and we may block users who do this
repeatedly or maliciously.

This is a rapidly-evolving situation that's causing significant shockwaves in the open-source community. As a result,
this policy is likely to be updated regularly in the near future. For more information, please read [`CONTRIBUTING.md`](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md).

- [x] I confirm that this is not a pure code agent PR.

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

@remi-or @ArthurZucker @McPatate

--- Comment by HuggingFaceDocBuilderDev at 2026-05-13T14:16:57Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45943). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

--- Comment by remi-or at 2026-05-14T02:26:36Z ---
Hey @sergiopaniego , thanks for the contribution! Good catch on both fronts, I just made some tiny changes:
- for the `attn_implementation` change, I lowered the change from the "context manager" scope to the "init manager" scope, so the change propagates no matter the entry point. I also applied the fix in case there is a persistent manager, because I think it could be a viable use case in TRL
- for the request counter change, I removed the `generate_batch`-side counter all together, rather relying on the actual list of request ids created by `add_requests`

Please lmk if those changes suit you, and if they still fix the bugs CB caused on TRL's side :) otherwise feel free to reverse ofc.

--- Comment by sergiopaniego at 2026-05-14T10:34:51Z ---
Tested the changes and everything is looking good, thanks!! @remi-or

--- Comment by sergiopaniego at 2026-05-14T12:45:44Z ---
actually I've detected an issue when training via fsdp2. With `@torch.inference_mode()`, it generates an exception (`inference tensors cannot be saved for backward`) since it seems like some inference tensors are in FSDP's internal state and they're accessed during the backward pass.
The fix applied is the same as for the standard `generate()`. Not sure if there's any performance impact on pure inference workloads, so happy to revisit if needed

--- Comment by remi-or at 2026-05-14T13:21:58Z ---
Let's leave it as is and I will check the impact in a future PR.


Revert 45777

PULL REQUEST #45942: Revert 45777
State: closed  |  Merged: True
Author: Rocketknight1  |  Base: main
Labels:
Created: 2026-05-13T12:25:57Z

#45777 removed some lines in the conftest which work around a torch issue, but the Torch fix hasn't propagated through to our CI version of Torch yet, so we need to put them back for now!

cc @vasqu

--- Comment by Rocketknight1 at 2026-05-13T12:34:11Z ---
cc @ydshieh @khushali9, what version of Torch do we need in the CI before we can remove those lines again?

--- Comment by HuggingFaceDocBuilderDev at 2026-05-13T12:37:08Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45942). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

--- Comment by ydshieh at 2026-05-13T17:42:55Z ---
it's torch 2.12, not released yet I think

--- Comment by khushali9 at 2026-05-13T18:17:48Z ---
 @Rocketknight1 I checked it is not 2.12 but the next release 2.13 on June 8.  I will keep a check and create my PR again to have it merge once Pytorch version is released. cc @ydshieh Thanks!

--- Comment by ydshieh at 2026-05-13T18:42:28Z ---
Oh yes, sorry indeed 2.13. Thank you for handling it.

You can use  `is_torch_greater_or_equal` from `src/transformers/utils/__init__.py` that is defined in `src/transformers/utils/import_utils.py`

--- Comment by khushali9 at 2026-05-14T19:54:29Z ---
Sure @ydshieh thanks

--- Comment by vasqu at 2026-05-13T12:28:28Z ---
Could we check the torch version for this block where the fix exists?


PULL REQUEST #45940: cache_utils: fix StaticSlidingWindowLayer.get_mask_sizes returning sliding_window size before cache is full
State: closed  |  Merged: False
Author: Dev-X25874  |  Base: main
Labels:
Created: 2026-05-13T10:45:04Z

# What does this PR do?

Fixes a bug in `StaticSlidingWindowLayer.get_mask_sizes` where `kv_length` was
incorrectly returned as `sliding_window` (the static maximum) during the
warm-up phase when the cache is not yet full and won't overflow on the current
update.

### Root cause

`get_mask_sizes` is called before `cache.update()` to determine the shape of
the 4-D attention mask `(batch, 1, query_length, kv_length)`. In the "not yet
full" branch, the method returned `kv_length = sliding_window` instead of the
actual number of tokens present (`cumulative_length_int + query_length`). This
caused the model to attend over zero-initialized padding positions in the
key/value tensors for every forward pass until the cache reached capacity,
corrupting attention scores during the warm-up phase.

### Fix

Replace `kv_length = sliding_window` with
`kv_length = self.cumulative_length_int + query_length` in the `else` branch,
making `StaticSlidingWindowLayer` consistent with `DynamicSlidingWindowLayer`,
which already handles this case correctly (lines 243–253).

- [x] I confirm that this is not a pure code agent PR.

## 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?
- [ ] Did you write any new necessary tests?

## Who can review?
@ArthurZucker @Cyrilvallez

--- Comment by github-actions[bot] at 2026-05-13T15:13:43Z ---
This PR was flagged by our automated quality checks. If you're a genuine
contributor, please reply here and a maintainer will review your PR.

Common reasons for flagging:
- New GitHub account
- Unusually high number of repository forks in a 24-hour window

We appreciate your contribution and apologize if this is a false positive!

--- Comment by github-actions[bot] at 2026-05-13T15:13:56Z ---
View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=45940&sha=80b3e9

--- Comment by Dev-X25874 at 2026-05-13T15:45:32Z ---
I’m a genuine contributor (not a code agent). This PR fixes StaticSlidingWindowLayer.get_mask_sizes returning sliding_window instead of the true KV length during warm-up, which made the model attend over padded positions until the cache filled up.

--- Comment by tarekziade at 2026-05-13T21:19:26Z ---
> I’m a genuine contributor (not a code agent). This PR fixes StaticSlidingWindowLayer.get_mask_sizes returning sliding_window instead of the true KV length during warm-up, which made the model attend over padded positions until the cache filled up.

Thanks, and sorry for the false positive!

--- Comment by Dev-X25874 at 2026-05-14T01:18:38Z ---
After tracing through the causal mask logic carefully, the original
code is correct. When the cache is not yet full, returning
`kv_length = sliding_window` is intentional — the static KV tensor
is always pre-allocated to that size, and the causal mask already
prevents attention to zero-padded positions. My fix was wrong and
the CI failures confirmed it. Sorry for the noise, closing this PR.

--- Comment by Cyrilvallez at 2026-05-15T04:50:19Z ---
Yes, there is no bug there!

--- Comment by sergereview[bot] at 2026-05-13T21:18:25Z ---
This fix is correct — `kv_length` should reflect the actual number of tokens present (`cumulative_length_int + query_length`), not the static buffer size. This aligns with `DynamicSlidingWindowLayer.get_mask_sizes` (line 251) and prevents the attention mask from covering zero-initialized padding during the warm-up phase.


PULL REQUEST #45936: Fix models for which we don't have a dedicated tokenizer class, and the listed one is incorrect
State: open  |  Merged: False
Author: itazap  |  Base: main
Labels:
Created: 2026-05-13T07:53:44Z

we don't check the tokenization of all the model paths we have in the transformers repo. Fixes https://github.com/huggingface/transformers/issues/45488, Related to https://github.com/huggingface/transformers/pull/44255

We have models that don't have their own dedicated Tokenizer class and use another model's tokenizer (ex. Granite which uses GPT2Tokenizer - related issue: https://github.com/huggingface/transformers/pull/45813) ). The different model tokenizer class would be mapped in the `tokenization_auto.py` mapping, or in the `tokenization_config.json`. Sometimes the mapped tokenizer isn't actually the one that is being used, and v5 surfaced these incorrect mappings. In order to "stay true to" the pre-v5 behavior of these models, we can map them to `TokenizersBackend` (eq. to `PreTrainedTokenizerFast` in v4) which loads the `tokenizer.json` as is. This happens because in v5 we actually try to load the mapped tokenizer class and force the same tokenizer type.

Anyway we only test tokenization of models that have their own tokenizer class but we should test tokenization for **every checkpoint we have in the repo**!

## This PR

### tools/tokenizer_compare/run_equivalence_comparison_all_checkpoints.py script
(based on that in https://github.com/huggingface/transformers/pull/44255)

```
python tools/tokenizer_compare/run_equivalence_comparison_all_checkpoints.py
  --rerun-from-results tools/tokenizer_compare/output/tokenizer_compare_result.json
  --output output/tokenizer_compare_results_rerun.json

```

scans `tests/models/test_modeling_*.py` for `.from_pretrained(...)` and extracts all the checkpoint paths we list, and compares _tokenizers loaded via `AutoTokenizer.from_pretrained` vs `TokenizersBackend.from_pretrained`.

### tools/tokenizer_compare/compare_tokenizer_xlni_roundtrip.py script

check if `TokenziersBackend` and `AutoTokenizer` behave the same way, producing same roundtrip results on xlni and generate the same token ids

```
python tools/tokenizer_compare/compare_tokenizer_xlni_roundtrip.py bigcode/tiny_starcoder_py v1 --backend tokenizers --compare-backend auto
```

## Report

PRE this PR / Fixes - on all the checkpoints we list: [report](https://htmlpreview.github.io/?https://raw.githubusercontent.com/huggingface/transformers/check_repo_model_tokenizers/tools/tokenizer_compare/output/tokenizer_compare_results_original.html)

POST this PR / Fixes: [report](https://htmlpreview.github.io/?https://raw.githubusercontent.com/huggingface/transformers/check_repo_model_tokenizers/tools/tokenizer_compare/output/tokenizer_compare_results_rerun.html)
### Remaining patterns: ###

#### Pattern 1 & 2

Expected and safe to ignore

- these behave identically as per (`tools/tokenizer_compare/compare_tokenizer_xlni_roundtrip.py`). These are legacy llama (already caught here: https://github.com/huggingface/transformers/pull/44255)

#### Pattern 3

- opened a PR on the hub https://huggingface.co/allenai/dolma2-tokenizer/discussions/1 , there is no `config.json` so we cannot force `TokenizersBackend` from `tokenization_auto.py`

#### Pattern 4

- opened a PR on the hub https://huggingface.co/google/umt5-small/discussions/2 [google/umt5-small](https://huggingface.co/google/umt5-small)

## TODO

adding a test that will check AutoTokenizer and TokenizersBackend loads equivalent _tokenizer objects for each path we mention in the repo

--- Comment by HuggingFaceDocBuilderDev at 2026-05-13T08:05:19Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45936). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

--- Comment by github-actions[bot] at 2026-05-20T02:50:50Z ---
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: albert, aria, auto, camembert, mpnet, rembert, xglm, xlnet

--- Comment by github-actions[bot] at 2026-05-20T03:24:00Z ---
View the CircleCI Test Summary for this PR:

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


PULL REQUEST #45935: Security: Add TRUST_REMOTE_CODE guard to nanochat checkpoint conversion
State: closed  |  Merged: False
Author: anxovatomica  |  Base: main
Labels: Code agent slop
Created: 2026-05-13T07:23:53Z

## Summary

This PR adds a `TRUST_REMOTE_CODE` environment variable guard before the `pickle.load()` call in `convert_nanochat_checkpoints.py`.

## Problem

The `write_tokenizer()` function in `src/transformers/models/nanochat/convert_nanochat_checkpoints.py` uses `pickle.load()` to deserialize `tokenizer.pkl` files during model conversion. Without an explicit opt-in, this could allow arbitrary code execution if the pickle file comes from an untrusted or compromised source (CWE-502 / insecure deserialization).

## Solution

Add the same `TRUST_REMOTE_CODE` guard that already exists in:
- `convert_olmo3_weights_to_hf.py`
- `convert_reformer_trax_checkpoint_to_pytorch.py`
- `convert_maskformer_resnet_to_pytorch.py`
- `retrieval_rag.py`
- `convert_perceiver_haiku_to_pytorch.py`

This ensures users must explicitly set `TRUST_REMOTE_CODE=True` before the conversion script will unpickle data.

## Changes

- Import `strtobool` from `...utils`
- Add guard check before `pickle.load()` in `write_tokenizer()`

## Testing

- `python -m py_compile src/transformers/models/nanochat/convert_nanochat_checkpoints.py` passes
- Pattern is consistent with all other conversion scripts in the codebase

--- Comment by github-actions[bot] at 2026-05-13T08:43:08Z ---
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: nanochat

--- Comment by Rocketknight1 at 2026-05-13T13:00:22Z ---
Blocked for multiple PRs of clearly pointless code agent spam. The conversion files are excluded from release builds and are present as a developer convenience only. They cannot be made secure because they have to load the original model artifacts, which are often insecure formats.


pass the otel secrets

PULL REQUEST #45933: pass the otel secrets
State: closed  |  Merged: True
Author: tarekziade  |  Base: main
Labels:
Created: 2026-05-13T06:25:45Z

# What does this PR do?

Pass the secrets to run OTEL

tested in https://github.com/huggingface/transformers/pull/45932

--- Comment by HuggingFaceDocBuilderDev at 2026-05-13T06:38:41Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45933). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

--- Comment by ydshieh at 2026-05-13T08:09:37Z ---
Maybe we could use

```
secrets: inherit
```

here?

--- Comment by tarekziade at 2026-05-13T08:11:42Z ---
I am thinking let's stay explicit and pass only those, as we will remove them soon anyways


DO NOT MERGE testing grafana

PULL REQUEST #45932: DO NOT MERGE testing grafana
State: open  |  Merged: False
Author: tarekziade  |  Base: main
Labels:
Created: 2026-05-13T06:04:19Z

test do not merge

--- Comment by HuggingFaceDocBuilderDev at 2026-05-13T06:30:10Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45932). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

--- Comment by github-actions[bot] at 2026-05-13T09:28:38Z ---
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: aimv2, auto, d_fine, deimv2, pp_doclayout_v2, pp_doclayout_v3, qwen3, qwen3_omni_moe, rt_detr, rt_detr_v2, vit_mae

--- Comment by github-actions[bot] at 2026-05-13T09:41:41Z ---
View the CircleCI Test Summary for this PR:

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

--- Comment by sergereview[bot] at 2026-05-13T06:40:41Z ---
This default is invalid. The function validates `embed_dim % 4 == 0` on line 160 and will raise `ValueError` for 257. The same bug is copy-pasted into `aimv2`, `d_fine`, `deimv2`, `pp_doclayout_v2`, `pp_doclayout_v3`, `rt_detr`, `rt_detr_v2`, and `modular_vit_mae.py`.

--- Comment by sergereview[bot] at 2026-05-13T06:40:41Z ---
Renaming the canonical `model_type` from `"qwen3"` to `"qwen42"` breaks AutoConfig / AutoModel registration for every Qwen3 checkpoint. This also leaves `auto_mappings.py` with a dangling `"qwen42"` entry that points to `Qwen3Config`, which is confusing and incorrect.

--- Comment by sergereview[bot] at 2026-05-13T06:40:41Z ---
Same issue: changing `model_type` to `"qwen42"` collides with the Qwen3 config and breaks the model registry.

--- Comment by sergereview[bot] at 2026-05-13T06:40:41Z ---
This mapping is broken: `"qwen42"` is not a real model architecture, and it replaces the legitimate `"qwen3"` entry. All Qwen3 model loading will fail.

--- Comment by sergereview[bot] at 2026-05-13T06:40:41Z ---
These CI secrets appear unrelated to any model bug fix. If this is experimental Grafana instrumentation, it should not be part of a model-correctness PR.


Add TurboQuant KV cache backend

PULL REQUEST #45931: Add TurboQuant KV cache backend
State: closed  |  Merged: False
Author: Yeuvoir  |  Base: main
Labels: Code agent slop
Created: 2026-05-13T05:45:38Z

# What does this PR do?

This PR adds a Transformers-native `TurboQuantCache` backend for quantized KV cache generation.

TurboQuant is an online vector quantization method for KV-cache compression. It normalizes KV vectors, applies a data-oblivious random rotation, quantizes rotated coordinates with Lloyd-Max scalar codebooks, and optionally applies a 1-bit QJL residual correction for inner-product preservation. The TurboQuant paper reports near-optimal distortion rates and strong KV-cache results, including quality neutrality around 3.5 bits per channel and marginal degradation around 2.5 bits per channel.

KV cache memory is one of the main memory constraints for long-context generation. A cache-level TurboQuant backend lets users reduce KV-cache memory while staying inside the standard `generate()` / `Cache` API.

vLLM has also recently added TurboQuant KV-cache quantization support through `--kv-cache-dtype turboquant_*` variants. This PR brings the same class of KV-cache compression to Transformers, exposed through the existing quantized cache generation path:

```python
cache_implementation="quantized"
cache_config={"backend": "turboquant"}
```

This PR adds:

- `TurboQuantQuantizedLayer`
- `TurboQuantCache`
- `backend="turboquant"` support in `QuantizedCache`
- generation integration for `cache_config={"backend": "turboquant"}`
- PyTorch dummy exports
- cache utility tests and a tiny end-to-end generation smoke test

References:

- TurboQuant paper: https://huggingface.co/papers/2504.19874
- vLLM TurboQuant docs: https://docs.vllm.ai/en/stable/api/vllm/model_executor/layers/quantization/turboquant/
- vLLM TurboQuant blog: https://vllm.ai/blog/turboquant

# Validation

Unit and style checks:

```bash
.venv/bin/python -m pytest tests/utils/test_cache_utils.py::CacheTest -q
# 5 passed

.venv/bin/python -m ruff check src/transformers/__init__.py src/transformers/cache_utils.py src/transformers/generation/utils.py src/transformers/utils/dummy_pt_objects.py tests/utils/test_cache_utils.py
# All checks passed

.venv/bin/python -m ruff format --check src/transformers/__init__.py src/transformers/cache_utils.py src/transformers/generation/utils.py src/transformers/utils/dummy_pt_objects.py tests/utils/test_cache_utils.py
# 5 files already formatted

.venv/bin/python utils/check_dummies.py
git diff --check
```

## End-to-end Transformers generation

End-to-end generation was validated with locally cached model weights on an NVIDIA H100 GPU.

Long-context test on `Qwen/Qwen3-8B`:

| cache | input tokens | generated tokens | final cache | allocation delta | peak delta | time |
|---|---:|---:|---:|---:|---:|---:|
| `DynamicCache` | 4096 | 32 | 580.36 MiB | 612.39 MiB | 1026.06 MiB | 2.87s |
| `TurboQuantCache`, nbits=3 | 4096 | 32 | 123.61 MiB | 123.64 MiB | 537.31 MiB | 4.32s |
| `TurboQuantCache`, nbits=2 | 4096 | 32 | 87.61 MiB | 87.64 MiB | 501.31 MiB | 3.25s |

Compared with `DynamicCache`:

- `TurboQuantCache`, nbits=3: 78.70% final cache reduction, 47.63% peak allocation reduction
- `TurboQuantCache`, nbits=2: 84.90% final cache reduction, 51.14% peak allocation reduction

Additional end-to-end smoke tests with `TurboQuantCache`, nbits=3:

| model | input tokens | generated tokens | DynamicCache final cache | TurboQuantCache final cache | cache reduction | Dynamic peak delta | TurboQuant peak delta | peak reduction |
|---|---:|---:|---:|---:|---:|---:|---:|---:|
| `Qwen/Qwen3-0.6B` | 1024 | 16 | 113.64 MiB | 27.45 MiB | 75.84% | 170.52 MiB | 104.08 MiB | 38.96% |
| `Qwen/Qwen2.5-0.5B-Instruct` | 1024 | 16 | 12.18 MiB | 3.46 MiB | 71.59% | 48.77 MiB | 39.05 MiB | 19.93% |
| `Qwen/Qwen3-1.7B` | 1024 | 16 | 113.64 MiB | 27.45 MiB | 75.84% | 164.52 MiB | 110.08 MiB | 33.09% |
| `unsloth/Llama-3.2-3B-Instruct` | 1024 | 16 | 113.64 MiB | 27.45 MiB | 75.84% | 184.52 MiB | 118.08 MiB | 36.01% |

Also verified the default generation path on `Qwen/Qwen3-8B`:

```python
cache_implementation="quantized"
cache_config={"backend": "turboquant"}
```

with 512 input tokens and 8 generated tokens. The returned cache type was `TurboQuantCache`.

## kvpress validation

I also validated the TurboQuant behavior in the local `kvpress` evaluation framework, using the existing TurboQuant press path to compare against an uncompressed baseline and reproduce the expected TurboQuant paper trend.

Setup:

- model: `unsloth/Llama-3.2-3B-Instruct`
- benchmark: LongBench `hotpotqa`
- samples: 40
- compression setting: `fraction=0.100`, `key_channel_cr=0.25`
- compared methods:
  - no compression
  - TurboQuant b8
  - TurboQuant b4
  - TurboQuant b3

Results:

| model | task | method | score | compression ratio |
|---|---|---:|---:|---:|
| `unsloth/Llama-3.2-3B-Instruct` | `hotpotqa` | no press | 60.83 | 0.00 |
| `unsloth/Llama-3.2-3B-Instruct` | `hotpotqa` | TurboQuant b8 | 63.89 | 0.50 |
| `unsloth/Llama-3.2-3B-Instruct` | `hotpotqa` | TurboQuant b4 | 58.06 | 0.75 |
| `unsloth/Llama-3.2-3B-Instruct` | `hotpotqa` | TurboQuant b3 | 47.86 | 0.81 |

These local kvpress results reproduce the expected TurboQuant paper behavior: higher-bit TurboQuant preserves LongBench quality close to the uncompressed baseline while substantially reducing KV cache storage, and lower-bit settings trade more quality for higher compression.

--- Comment by Yeuvoir at 2026-05-15T12:48:36Z ---
@ArthurZucker
Hi maintainers,
This PR adds a TurboQuant KV cache backend following the existing cache interface in Transformers.

I’ve tested the implementation locally.

Would appreciate a review when you have time. Thanks!

--- Comment by Rocketknight1 at 2026-05-15T14:39:51Z ---
Sorry, this just looks like code agent output! We'd really prefer if people opened an issue to check if there was interest in a feature before dropping 500 lines of Claude on us and asking us to review it


PULL REQUEST #45930: [DeepSeek V4] Fix MoE converter substring-matching FP8 scale companions
State: closed  |  Merged: True
Author: qgallouedec  |  Base: main
Labels:
Created: 2026-05-13T03:40:48Z

see #45794

--- Comment by github-actions[bot] at 2026-05-13T03:51:39Z ---
View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=45930&sha=3b5ba3

--- Comment by HuggingFaceDocBuilderDev at 2026-05-13T03:52:29Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45930). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

--- Comment by qgallouedec at 2026-05-13T18:40:00Z ---
```python
import torch, tempfile
from torch import nn
from transformers import DeepseekV4Config, DeepseekV4ForCausalLM
from transformers.models.deepseek_v4.modeling_deepseek_v4 import DeepseekV4Experts

cfg = DeepseekV4Config(
    vocab_size=128, hidden_size=8, num_attention_heads=4, num_key_value_heads=1, num_hidden_layers=2, intermediate_size=32,
    quantization_config={"activation_scheme": "dynamic", "fmt": "e4m3", "quant_method": "fp8", "scale_fmt": "ue8m0", "weight_block_size": [128, 128]},
)
m = DeepseekV4ForCausalLM(cfg).to(dtype=torch.bfloat16)

def cdiv(a, b):
    return (a + b - 1) // b

# Attach all FP8 scale companions, matching what DeepSeek-v4 has.
for name, mod in m.named_modules():
    if isinstance(mod, nn.Linear) and not name.endswith("lm_head"):
        of, inf = mod.out_features, mod.in_features
        mod.register_parameter("weight_scale_inv", nn.Parameter(torch.ones(cdiv(of, 128), cdiv(inf, 128)), requires_grad=False))
    elif isinstance(mod, DeepseekV4Experts):
        n, gu_o, gu_i = mod.gate_up_proj.shape
        _, d_o, d_i = mod.down_proj.shape
        mod.register_parameter("gate_up_proj_scale_inv", nn.Parameter(torch.ones(n, cdiv(gu_o, 128), cdiv(gu_i, 128)), requires_grad=False))
        mod.register_parameter("down_proj_scale_inv", nn.Parameter(torch.ones(n, cdiv(d_o, 128), cdiv(d_i, 128)), requires_grad=False))

with tempfile.TemporaryDirectory() as d:
    m.save_pretrained(d)  # before fix: raises Undefined Operation
    model = DeepseekV4ForCausalLM.from_pretrained(d)

for name, param in model.named_parameters():
    print(name, param.shape, param.dtype)
```

`main`:

```
[transformers] Unrecognized keys in `rope_parameters` for 'rope_type'='default': {'attention_factor'}
[transformers] Unrecognized keys in `rope_parameters` for 'rope_type'='default': {'attention_factor'}
[transformers] Unrecognized keys in `rope_parameters` for 'rope_type'='default': {'attention_factor'}
[transformers] Unrecognized keys in `rope_parameters` for 'rope_type'='default': {'attention_factor'}
Traceback (most recent call last):
  File "/fsx/qgallouedec/transformers/repro.py", line 29, in <module>
    m.save_pretrained(d)  # before fix: raises Undefined Operation
    ~~~~~~~~~~~~~~~~~^^^
  File "/fsx/qgallouedec/transformers/src/transformers/modeling_utils.py", line 3461, in save_pretrained
    state_dict = revert_weight_conversion(model_to_save, state_dict)
  File "/fsx/qgallouedec/transformers/src/transformers/core_model_loading.py", line 1541, in revert_weight_conversion
    realized = mapping.convert(layer_name, model=model, config=model.config)
  File "/fsx/qgallouedec/transformers/src/transformers/core_model_loading.py", line 920, in convert
    collected_tensors = op.convert(
        collected_tensors,
    ...<6 lines>...
        missing_keys=loading_info.missing_keys if loading_info else None,
    )
  File "/fsx/qgallouedec/miniconda3/envs/trl/lib/python3.13/site-packages/torch/utils/_contextlib.py", line 124, in decorate_context
    return func(*args, **kwargs)
  File "/fsx/qgallouedec/transformers/src/transformers/core_model_loading.py", line 237, in convert
    targets = self.get_target_patterns(input_dict, source_pattern, target_patterns, sizes)
  File "/fsx/qgallouedec/transformers/src/transformers/core_model_loading.py", line 251, in get_target_patterns
    raise ValueError("Undefined Operation encountered!")
ValueError: Undefined Operation encountered!
```

this branch

```
$ /fsx/qgallouedec/miniconda3/envs/trl/bin/python /fsx/qgallouedec/transformers/repro.py
[transformers] Unrecognized keys in `rope_parameters` for 'rope_type'='default': {'attention_factor'}
[transformers] Unrecognized keys in `rope_parameters` for 'rope_type'='default': {'attention_factor'}
[transformers] Unrecognized keys in `rope_parameters` for 'rope_type'='default': {'attention_factor'}
[transformers] Unrecognized keys in `rope_parameters` for 'rope_type'='default': {'attention_factor'}
Writing model shards: 100%|██████████████████████████████████████████████████████| 1/1 [00:00<00:00, 18.71it/s]
[transformers] Unrecognized keys in `rope_parameters` for 'rope_type'='default': {'attention_factor'}
[transformers] Unrecognized keys in `rope_parameters` for 'rope_type'='default': {'attention_factor'}
[transformers] You have loaded an FP8 model on CPU and have a CUDA or XPU device available, make sure to set your model on a GPU or XPU device in order to run your model. To remove this warning, pass device_map = 'cuda' or 'xpu'.
Loading weights: 100%|████████████████████████████████████████████████████████| 84/84 [00:00<00:00, 759.21it/s]
model.embed_tokens.weight torch.Size([128, 8]) torch.bfloat16
model.layers.0.self_attn.sinks torch.Size([4]) torch.bfloat16
model.layers.0.self_attn.q_a_proj.weight torch.Size([1024, 8]) torch.float8_e4m3fn
model.layers.0.self_attn.q_a_proj.weight_scale_inv torch.Size([8, 1]) torch.float32
model.layers.0.self_attn.q_a_norm.weight torch.Size([1024]) torch.float32
model.layers.0.self_attn.q_b_proj.weight torch.Size([2048, 1024]) torch.float8_e4m3fn
model.layers.0.self_attn.q_b_proj.weight_scale_inv torch.Size([16, 8]) torch.float32
model.layers.0.self_attn.kv_proj.weight torch.Size([512, 8]) torch.float8_e4m3fn
model.layers.0.self_attn.kv_proj.weight_scale_inv torch.Size([4, 1]) torch.float32
model.layers.0.self_attn.kv_norm.weight torch.Size([512]) torch.float32
model.layers.0.self_attn.o_a_proj.weight torch.Size([8192, 256]) torch.float8_e4m3fn
model.layers.0.self_attn.o_a_proj.weight_scale_inv torch.Size([64, 2]) torch.float32
model.layers.0.self_attn.o_b_proj.weight torch.Size([8, 8192]) torch.float8_e4m3fn
model.layers.0.self_attn.o_b_proj.weight_scale_inv torch.Size([1, 64]) torch.float32
...
```

--- Comment by vasqu at 2026-05-18T07:05:06Z ---
Wouldn't this change make sense on all MoE models? Since, we do want to support native FP8 versions in any case imo


Deepseek v4 csa mask collapse

PULL REQUEST #45928: Deepseek v4 csa mask collapse
State: closed  |  Merged: True
Author: ArthurZucker  |  Base: main
Labels: for patch
Created: 2026-05-13T02:42:54Z

# What does this PR do?

See https://github.com/huggingface/transformers/pull/45892#issuecomment-4432108446 I think its worth having

--- Comment by github-actions[bot] at 2026-05-13T02:47:22Z ---
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: deepseek_v4

--- Comment by HuggingFaceDocBuilderDev at 2026-05-13T03:04:59Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45928). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

--- Comment by vadimkantorov at 2026-05-13T15:33:11Z ---
Is `full_like` needed? Modern `torch.where` can handle scalar arguments / or broadcast directly

--- Comment by vasqu at 2026-05-13T16:21:02Z ---
my immediate thought is that it can cause device syncs if you use normal scalars so it's likely easier to create the tensor at that scale


PULL REQUEST #45927: Expose `per_layer_inputs` for every Gemma4 variants
State: closed  |  Merged: True
Author: Cyrilvallez  |  Base: main
Labels:
Created: 2026-05-13T02:32:47Z

# What does this PR do?

As per the title. Fixes https://github.com/huggingface/transformers/issues/45874. They were not properly exposed on the 2 top-most multimodals models, which means they would be recomputed from `inputs_embeds` sometimes, which is expensive.

--- Comment by HuggingFaceDocBuilderDev at 2026-05-13T02:43:50Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45927). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

--- Comment by thijs-vanweezel at 2026-05-13T20:48:34Z ---
The proposed changes align with my suggestion and look good to me! If there's anything you would like me to do, let me know. I'm quite busy now, but will soon check whether the fix propagates properly into `model.generate`.

Also, although it's slightly unrelated, is it worth noting that Gemma4Model takes `mm_token_type_ids` as argument, but ignores it in `get_placeholder_mask`?

--- Comment by github-actions[bot] at 2026-05-14T07:08:53Z ---
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: gemma4

--- Comment by thijs-vanweezel at 2026-05-18T20:04:55Z ---
@Cyrilvallez, just to quickly confirm `model.generate` does not process `inputs_embeds`+`per_layer_inputs` the way one would expect. Namely, after the initial prefill, `generate` relies on the newly created token as argument for `input_ids`, and therefore should subsequently ignore `inputs_embeds` and `per_layer_inputs`. However, it currently passes the provided `per_layer_inputs` as argument at every generation step, which does not correspond with the actual new token. Therefore, it results in an error like:

`RuntimeError: The expanded size of the tensor (81) must match the existing size (55) at non-singleton dimension 3.  Target sizes: [1, 8, 27, 81].  Tensor sizes: [1, 1, 1, 55]`

To fix this, we could consider overwriting the `_update_model_kwargs_for_generation` from generation>utils.py at the model level, in order to null out the `per_layer_inputs` after the first generation step:

```
def _update_model_kwargs_for_generation(self, outputs, model_kwargs, **kwargs):
    model_kwargs = super()._update_model_kwargs_for_generation(outputs, model_kwargs, **kwargs)
    model_kwargs["per_layer_inputs"] = None
    return model_kwargs
```

Because right now, one would either need to manually implement the entire autoregressive loop or at least the prefill.

--- Comment by Cyrilvallez at 2026-05-19T02:28:52Z ---
@thijs-vanweezel ha damn, may be an issue indeed, let me check!

--- Comment by Cyrilvallez at 2026-05-13T02:33:43Z ---
This is the important change, before they would be recomputed no matter what if provided

--- Comment by vasqu at 2026-05-13T08:26:12Z ---
For BC reasons, we should probably move the new arg to the end (in case users passed args)

--- Comment by vasqu at 2026-05-13T08:26:24Z ---
Sounds good!

--- Comment by Cyrilvallez at 2026-05-14T06:04:11Z ---
Yeah kept it after `inputs_embeds` because it makes more sense to me, but I'll move it!


PULL REQUEST #45926: hyperclovax: add XPU Expectations for CI test
State: closed  |  Merged: True
Author: kaixuanliu  |  Base: main
Labels:
Created: 2026-05-13T02:16:21Z

@ydshieh pls help review, thx!

--- Comment by github-actions[bot] at 2026-05-13T02:17:23Z ---
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: hyperclovax


PULL REQUEST #45924: Fix AutoTokenizer using wrong tokenizer class for olmo2, granite, granitemoehybrid, hyperclovax, and ernie models
State: closed  |  Merged: False
Author: rmotgi1227  |  Base: main
Labels:
Created: 2026-05-12T21:21:10Z

Fixes #45920

Several model types have a `tokenizer_class` field in their Hub `tokenizer_config.json` that points to a slow tokenizer (e.g., `GPT2Tokenizer`, `LlamaTokenizer`), while the model was actually trained with the corresponding fast tokenizer. When `AutoTokenizer.from_pretrained()` loads these models, it instantiates the slow variant, producing incorrect token IDs because the slow and fast tokenizers have different pretokenization algorithms.

This is the same root cause as the already-fixed `deepseek_v2`, `deepseek_v3`, `deepseek_v4`, and `qwen2` entries in `MODELS_WITH_INCORRECT_HUB_TOKENIZER_CLASS`. This PR extends that fix to cover five more affected model families:

- `olmo2` — affected models include `allenai/OLMo-2-0425-1B` (~83K monthly downloads). Hub `tokenizer_class` is `GPT2Tokenizer`, should use `TokenizersBackend`.
- - `granite` / `granitemoehybrid` — affected models include `ibm-granite/granite-4.1-8b` (~14K), `ibm-granite/granite-4.0-micro` (~400K). Hub `tokenizer_class` is `GPT2Tokenizer`.
- - `hyperclovax` — affected models include `naver-hyperclovax/HyperCLOVAX-SEED-Think-14B` (~39K). Hub `tokenizer_class` is `GPT2Tokenizer`. (`hyperclovax_vlm` was already in the list, but the base `hyperclovax` model type was missing.)
- - `ernie` — affected models include `baidu/ERNIE-4.5-21B-A3B-Thinking` (~35K). Hub `tokenizer_class` is `LlamaTokenizer`.
Users can verify the regression by comparing `AutoTokenizer.from_pretrained(model_id)` output against `PreTrainedTokenizerFast.from_pretrained(model_id)` — without this fix, they return different token IDs for the same input string.

--- Comment by github-actions[bot] at 2026-05-12T21:22:20Z ---
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: auto

--- Comment by Rocketknight1 at 2026-05-13T12:46:36Z ---
This doesn't seem wrong, but I'm closing because @itazap is working on a broader PR that should fix this, see https://github.com/huggingface/transformers/issues/45920


PULL REQUEST #45922: 🚨Fix memory leaks caused by lru decorators in vision models
State: closed  |  Merged: True
Author: yonigozlan  |  Base: main
Labels:
Created: 2026-05-12T20:59:12Z

Lru decorators were keeping references to entire models causing memory to not be freed when deleting the models

Fixes https://github.com/huggingface/transformers/issues/45412

Breaking changes:
- text_embeds input in sam3/edgetam/sam3_lite_text is now expected to be full text embeds and not just pooler outputs, to be coherent with other models and the existing doc .
- change attr num_pos_feats to num_position_features in several models in an effort to standardize attr names across models

--- Comment by yonigozlan at 2026-05-12T21:06:47Z ---
run-slow: beit, conditional_detr, d_fine, data2vec, deformable_detr, deimv2, detr, edgetam, edgetam_video, mask2former, maskformer, oneformer, pp_doclayout_v2, pp_doclayout_v3, rt_detr, rt_detr_v2, sam2, sam2_video, sam3, sam3_lite_text, sam3_tracker, sam3_tracker_video

--- Comment by github-actions[bot] at 2026-05-12T21:08:16Z ---
[Workflow Run ⚙](https://github.com/huggingface/transformers/actions/runs/25762253427)

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

models: ["models/beit", "models/conditional_detr", "models/d_fine", "models/data2vec", "models/deformable_detr", "models/deimv2", "models/detr", "models/edgetam", "models/edgetam_video", "models/mask2former", "models/maskformer", "models/oneformer", "models/pp_doclayout_v2", "models/pp_doclayout_v3", "models/rt_detr", "models/rt_detr_v2", "models/sam2", "models/sam2_video", "models/sam3", "models/sam3_lite_text", "models/sam3_tracker", "models/sam3_tracker_video"]
quantizations: []

--- Comment by HuggingFaceDocBuilderDev at 2026-05-12T21:13:05Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45922). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

--- Comment by github-actions[bot] at 2026-05-12T21:40:06Z ---
## CI Results
[Workflow Run ⚙](https://github.com/huggingface/transformers/actions/runs/25762253427)

### Commit Info
| Context | Commit | Description |
|---------|--------|-------------|
| RUN | [024b266b](https://github.com/huggingface/transformers/commit/024b266bc07282ce7a6afe93fb386c26fb52d8fb) | workflow commit (merge commit) |
| PR | [24b1cdde](https://github.com/yonigozlan/transformers/commit/24b1cdde94846335485ba84aded072aa5652c4ee) | branch commit (from PR) |
| main | [7ee56fc2](https://github.com/huggingface/transformers/commit/7ee56fc257b1dec80a03b7e4808aafe671699ace) | base commit (on `main`) |

⚠ **Model CI failed to report results**

The test failure analysis could not be completed. Please check the [workflow run](https://github.com/huggingface/transformers/actions/runs/25762253427) for details.

--- Comment by yonigozlan at 2026-05-12T22:22:48Z ---
run-slow: beit, conditional_detr, d_fine, data2vec, deformable_detr, deimv2, detr, edgetam, edgetam_video, mask2former, maskformer, oneformer, pp_doclayout_v2, pp_doclayout_v3, rt_detr, rt_detr_v2, sam2, sam2_video, sam3, sam3_lite_text, sam3_tracker, sam3_tracker_video

--- Comment by github-actions[bot] at 2026-05-12T22:24:11Z ---
[Workflow Run ⚙](https://github.com/huggingface/transformers/actions/runs/25765716372)

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

models: ["models/beit", "models/conditional_detr", "models/d_fine", "models/data2vec", "models/deformable_detr", "models/deimv2", "models/detr", "models/edgetam", "models/edgetam_video", "models/mask2former", "models/maskformer", "models/oneformer", "models/pp_doclayout_v2", "models/pp_doclayout_v3", "models/rt_detr", "models/rt_detr_v2", "models/sam2", "models/sam2_video", "models/sam3", "models/sam3_lite_text", "models/sam3_tracker", "models/sam3_tracker_video"]
quantizations: []

--- Comment by github-actions[bot] at 2026-05-12T22:43:57Z ---
## CI Results
[Workflow Run ⚙](https://github.com/huggingface/transformers/actions/runs/25765716372)

### Commit Info
| Context | Commit | Description |
|---------|--------|-------------|
| RUN | [14a5605c](https://github.com/huggingface/transformers/commit/14a5605c3cfb0c07f2701c89c84ed82754d678aa) | workflow commit (merge commit) |
| PR | [344c4c3a](https://github.com/yonigozlan/transformers/commit/344c4c3a1724681e14670591c0e46d1eeba4dc72) | branch commit (from PR) |
| main | [7ee56fc2](https://github.com/huggingface/transformers/commit/7ee56fc257b1dec80a03b7e4808aafe671699ace) | base commit (on `main`) |

⚠ **Model CI failed to report results**

The test failure analysis could not be completed. Please check the [workflow run](https://github.com/huggingface/transformers/actions/runs/25765716372) for details.

--- Comment by yonigozlan at 2026-05-13T14:57:18Z ---
Thanks for the review @vasqu ! Indeed it might be better to use staticmethod, I'll make the changes and ping you when it's ready :)

--- Comment by yonigozlan at 2026-05-13T21:14:18Z ---
run-slow: beit, conditional_detr, d_fine, data2vec, deformable_detr, deimv2, detr, edgetam, edgetam_video, mask2former, maskformer, oneformer, pp_doclayout_v2, pp_doclayout_v3, rt_detr, rt_detr_v2, sam2, sam2_video, sam3, sam3_lite_text, sam3_tracker, sam3_tracker_video

--- Comment by github-actions[bot] at 2026-05-13T21:16:08Z ---
[Workflow Run ⚙](https://github.com/huggingface/transformers/actions/runs/25826822289)

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

models: ["models/beit", "models/conditional_detr", "models/d_fine", "models/data2vec", "models/deformable_detr", "models/deimv2", "models/detr", "models/edgetam", "models/edgetam_video", "models/mask2former", "models/maskformer", "models/oneformer", "models/pp_doclayout_v2", "models/pp_doclayout_v3", "models/rt_detr", "models/rt_detr_v2", "models/sam2", "models/sam2_video", "models/sam3", "models/sam3_lite_text", "models/sam3_tracker", "models/sam3_tracker_video"]
quantizations: []

--- Comment by github-actions[bot] at 2026-05-13T21:56:51Z ---
## CI Results
[Workflow Run ⚙](https://github.com/huggingface/transformers/actions/runs/25826822289)

### Commit Info
| Context | Commit | Description |
|---------|--------|-------------|
| RUN | [98f1299d](https://github.com/huggingface/transformers/commit/98f1299d0590e5271ae6438ea7031976384ddc04) | workflow commit (merge commit) |
| PR | [4c8136f3](https://github.com/yonigozlan/transformers/commit/4c8136f314fce43212a923b54bbeb4eeb0ccdc4d) | branch commit (from PR) |
| main | [98a25186](https://github.com/huggingface/transformers/commit/98a2518663d5824ee0d2b01359d2083abe88a2b3) | base commit (on `main`) |

### Model CI Report

❌ **[29 new failed tests from this PR](https://huggingface.co/datasets/hf-internal-testing/transformers_pr_ci/raw/c10745abb940205b32b359e23adf1a2f88d9ce3a/2026-05-13/runs/34623-25826822289/ci_results_run_models_gpu/new_failures_with_bad_commit.json)** 😭

- [edgetam_video](https://github.com/huggingface/transformers/actions/runs/25826822289/job/75882794366):
    tests/models/edgetam_video/test_modeling_edgetam_video.py::EdgeTamVideoModelIntegrationTest::test_inference_mask_generation_video_multi_objects_multi_points (✅ ⟹ ❌)
    tests/models/edgetam_video/test_modeling_edgetam_video.py::EdgeTamVideoModelIntegrationTest::test_inference_mask_generation_video_multi_points (✅ ⟹ ❌)
    tests/models/edgetam_video/test_modeling_edgetam_video.py::EdgeTamVideoModelIntegrationTest::test_inference_mask_generation_video_one_bb (✅ ⟹ ❌)
    tests/models/edgetam_video/test_modeling_edgetam_video.py::EdgeTamVideoModelIntegrationTest::test_inference_mask_generation_video_one_point (✅ ⟹ ❌)
    tests/models/edgetam_video/test_modeling_edgetam_video.py::EdgeTamVideoModelIntegrationTest::test_inference_mask_generation_video_one_point_one_bb (✅ ⟹ ❌)
    tests/models/edgetam_video/test_modeling_edgetam_video.py::EdgeTamVideoModelIntegrationTest::test_inference_mask_generation_video_one_point_propagate_in_video_directly (✅ ⟹ ❌)
    tests/models/edgetam_video/test_modeling_edgetam_video.py::EdgeTamVideoModelIntegrationTest::test_inference_propagate_on_streamed_video (✅ ⟹ ❌)
    tests/models/edgetam_video/test_modeling_edgetam_video.py::EdgeTamVideoModelIntegrationTest::test_inference_propagate_video_from_mask_input (✅ ⟹ ❌)
    tests/models/edgetam_video/test_modeling_edgetam_video.py::EdgeTamVideoModelIntegrationTest::test_inference_with_different_dtypes (✅ ⟹ ❌)

- [sam2_video](https://github.com/huggingface/transformers/actions/runs/25826822289/job/75882794422):
    tests/models/sam2_video/test_modeling_sam2_video.py::Sam2VideoModelIntegrationTest::test_inference_mask_generation_video_batched_bb (✅ ⟹ ❌)
    tests/models/sam2_video/test_modeling_sam2_video.py::Sam2VideoModelIntegrationTest::test_inference_mask_generation_video_multi_objects_multi_points (✅ ⟹ ❌)
    tests/models/sam2_video/test_modeling_sam2_video.py::Sam2VideoModelIntegrationTest::test_inference_mask_generation_video_multi_points (✅ ⟹ ❌)
    tests/models/sam2_video/test_modeling_sam2_video.py::Sam2VideoModelIntegrationTest::test_inference_mask_generation_video_one_bb (✅ ⟹ ❌)
    tests/models/sam2_video/test_modeling_sam2_video.py::Sam2VideoModelIntegrationTest::test_inference_mask_generation_video_one_point (✅ ⟹ ❌)
    tests/models/sam2_video/test_modeling_sam2_video.py::Sam2VideoModelIntegrationTest::test_inference_mask_generation_video_one_point_one_bb (✅ ⟹ ❌)
    tests/models/sam2_video/test_modeling_sam2_video.py::Sam2VideoModelIntegrationTest::test_inference_mask_generation_video_one_point_propagate_in_video_directly (✅ ⟹ ❌)
    tests/models/sam2_video/test_modeling_sam2_video.py::Sam2VideoModelIntegrationTest::test_inference_propagate_on_streamed_video (✅ ⟹ ❌)
    tests/models/sam2_video/test_modeling_sam2_video.py::Sam2VideoModelIntegrationTest::test_inference_propagate_video_from_mask_input (✅ ⟹ ❌)
    tests/models/sam2_video/test_modeling_sam2_video.py::Sam2VideoModelIntegrationTest::test_inference_with_different_dtypes (✅ ⟹ ❌)

- [sam3_tracker_video](https://github.com/huggingface/transformers/actions/runs/25826822289/job/75882794502):
    tests/models/sam3_tracker_video/test_modeling_sam3_tracker_video.py::Sam3TrackerVideoModelIntegrationTest::test_inference_mask_generation_video_batched_bb (✅ ⟹ ❌)
    tests/models/sam3_tracker_video/test_modeling_sam3_tracker_video.py::Sam3TrackerVideoModelIntegrationTest::test_inference_mask_generation_video_multi_objects_multi_points (✅ ⟹ ❌)
    tests/models/sam3_tracker_video/test_modeling_sam3_tracker_video.py::Sam3TrackerVideoModelIntegrationTest::test_inference_mask_generation_video_multi_points (✅ ⟹ ❌)
    tests/models/sam3_tracker_video/test_modeling_sam3_tracker_video.py::Sam3TrackerVideoModelIntegrationTest::test_inference_mask_generation_video_one_bb (✅ ⟹ ❌)
    tests/models/sam3_tracker_video/test_modeling_sam3_tracker_video.py::Sam3TrackerVideoModelIntegrationTest::test_inference_mask_generation_video_one_point (✅ ⟹ ❌)
    tests/models/sam3_tracker_video/test_modeling_sam3_tracker_video.py::Sam3TrackerVideoModelIntegrationTest::test_inference_mask_generation_video_one_point_one_bb (✅ ⟹ ❌)
    tests/models/sam3_tracker_video/test_modeling_sam3_tracker_video.py::Sam3TrackerVideoModelIntegrationTest::test_inference_mask_generation_video_one_point_propagate_in_video_directly (✅ ⟹ ❌)
    tests/models/sam3_tracker_video/test_modeling_sam3_tracker_video.py::Sam3TrackerVideoModelIntegrationTest::test_inference_propagate_on_streamed_video (✅ ⟹ ❌)
    tests/models/sam3_tracker_video/test_modeling_sam3_tracker_video.py::Sam3TrackerVideoModelIntegrationTest::test_inference_propagate_video_from_mask_input (✅ ⟹ ❌)
    tests/models/sam3_tracker_video/test_modeling_sam3_tracker_video.py::Sam3TrackerVideoModelIntegrationTest::test_inference_with_different_dtypes (✅ ⟹ ❌)

--- Comment by yonigozlan at 2026-05-15T15:33:08Z ---
run-slow: beit, conditional_detr, d_fine, data2vec, deformable_detr, deimv2, detr, edgetam, edgetam_video, mask2former, maskformer, oneformer, pp_doclayout_v2, pp_doclayout_v3, rt_detr, rt_detr_v2, sam2, sam2_video, sam3, sam3_lite_text, sam3_tracker, sam3_tracker_video

--- Comment by github-actions[bot] at 2026-05-15T15:34:28Z ---
[Workflow Run ⚙](https://github.com/huggingface/transformers/actions/runs/25926444950)

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

models: ["models/beit", "models/conditional_detr", "models/d_fine", "models/data2vec", "models/deformable_detr", "models/deimv2", "models/detr", "models/edgetam", "models/edgetam_video", "models/mask2former", "models/maskformer", "models/oneformer", "models/pp_doclayout_v2", "models/pp_doclayout_v3", "models/rt_detr", "models/rt_detr_v2", "models/sam2", "models/sam2_video", "models/sam3", "models/sam3_lite_text", "models/sam3_tracker", "models/sam3_tracker_video"]
quantizations: []

--- Comment by yonigozlan at 2026-05-15T15:44:31Z ---
Waiting to see if all slow tests pass but it should be good to go then @vasqu !

--- Comment by vasqu at 2026-05-15T15:53:57Z ---
Sounds good, keeping an eye here to review later today :saluting_face:

--- Comment by github-actions[bot] at 2026-05-15T16:05:28Z ---
## CI Results
[Workflow Run ⚙](https://github.com/huggingface/transformers/actions/runs/25926444950)

### Commit Info
| Context | Commit | Description |
|---------|--------|-------------|
| RUN | [7fbd5dec](https://github.com/huggingface/transformers/commit/7fbd5deca8563d330cfa8eb4656e5f29c87220ae) | workflow commit (merge commit) |
| PR | [c307ba63](https://github.com/yonigozlan/transformers/commit/c307ba6351cc8a98eab59d130ff9e1d7e39b3ff9) | branch commit (from PR) |
| main | [331f1007](https://github.com/huggingface/transformers/commit/331f1007c381426aba57687b1ff9845f46b9de02) | base commit (on `main`) |

✅ No failing test specific to this PR 🎉 👏 !

--- Comment by github-actions[bot] at 2026-05-15T19:49:57Z ---
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: beit, conditional_detr, d_fine, dab_detr, data2vec, deformable_detr, deimv2, detr, edgetam, edgetam_video, got_ocr2, mask2former, maskformer, oneformer, pp_doclayout_v2, pp_doclayout_v3

--- Comment by vasqu at 2026-05-13T12:37:06Z ---
Just to be sure that I understood the root cause --> the lru cache saved a reference of self as it's a model's internal function?

Would it be possible to instead make these `staticmethod`? Might be a more natural move than all the private global fns

Anyways we do need to add 🚨 because it changes the behavior slightly and people might have relied on these internal functions

--- Comment by vasqu at 2026-05-13T12:40:11Z ---
Ah ok here we keep BC - we really need to decide what would be better ig but should be consistent then

--- Comment by vasqu at 2026-05-13T12:41:30Z ---
That is definitely breaking 👀 Any reason we could not keep the same behavior there?

--- Comment by yonigozlan at 2026-05-13T14:52:28Z ---
> Just to be sure that I understood the root cause --> the lru cache saved a reference of self as it's a model's internal function?

Yes, I'm not sure about the exact inner workings of lru_cache but as a general rule it's not good practice to apply them to instance methods. That was my mistake

> Would it be possible to instead make these staticmethod? Might be a more natural move than all the private global fns

That's a good point! I'll try to refactor with staticmethod instead, and make sure lru_cache doesn't cause issues when applied to static method (should be ok)

--- Comment by yonigozlan at 2026-05-13T14:55:43Z ---
I think it was broken before this fix, as the docs were already using the behavior of this PR, but it's a niche feature so maybe why it was never flagged. I'll add a 🚨

--- Comment by vasqu at 2026-05-15T16:42:06Z ---
lets use transpose instead of permute :D

--- Comment by vasqu at 2026-05-15T16:45:10Z ---
this wrapper structure is a bit awkward, could we move things here a bit to make it directly use `build_2d_sinusoidal_position_embedding` or is the inheritance too awkward?

--- Comment by vasqu at 2026-05-15T16:47:10Z ---
this is slightly breaking because of the rename

--- Comment by vasqu at 2026-05-15T16:47:29Z ---
transpose

--- Comment by yonigozlan at 2026-05-15T18:35:03Z ---
Not sure we can do that and still have it standardized everywhere it's used, because some models call build_2d_sinusoidal_position_embedding at init and copy the result in their weights, so they don't need to lru_cache it at all.


PULL REQUEST #45921: BUGFIX: Support hubert models that don't have conv_pos_batch_norm configured
State: closed  |  Merged: True
Author: igordertigor  |  Base: main
Labels:
Created: 2026-05-12T19:17:05Z

# What does this PR do?

In #34389 , introduced a new configuration flag `conv_pos_batch_norm` that allows using batch norm in the positional conv embeddings. Unfortunately, this new configuration flag is not necessarily present in older hubert pretrained models. By allowing the configuration flag to be absent (and then be treated as the default `False`), these older models work again.

I found this issue with the "m-a-p/MERT-v0" artifact.

- [x] I confirm that this is not a pure code agent PR.

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

The following people will likely be quite familiar with the code:
- @gallilmaimon submitted the PR that introduced the issue
- @ylacombe merged the PR that introduced the issue and acted as reviewer on that PR

--- Comment by github-actions[bot] at 2026-05-12T19:18:30Z ---
**[For maintainers]** Suggested jobs to run (before merge)

run-slow: hubert

--- Comment by HuggingFaceDocBuilderDev at 2026-05-13T13:05:22Z ---
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_45921). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.