noamaanMulla-03/transformers-issues huggingface dataset:
feat: build CI docker images for linux/arm64 (Graviton)
Author: glegendre01
Pull request: yes

## Summary

- Add `arm64` builds for all CPU CI images (`quality`, `consistency`, `custom-tokenizers`, `torch-light`, `exotic-models`, `examples-torch`) using the `aws-m8g-l-cache` HF runner group
- Restructure the workflow into three jobs:
  - **`build`** — matrix `file × arch`, builds each image natively per platform and pushes by digest
  - **`merge`** — creates a multi-arch manifest from the collected digests
  - **`notify`** — Slack notification, now waits for `merge` to complete
- On non-push runs (PR validation), the build step runs without pushing, and the merge/notify jobs are skipped

## How it works

`runs-on` uses `fromJSON(matrix.arch.runner)` so each arch targets the right runner:
- `amd64` → `ubuntu-22.04`
- `arm64` → `{"group": "aws-m8g-l-cache"}`

The push path uses `push-by-digest` + `docker buildx imagetools create` (same pattern as `actions-runner-image`).

## Test plan

- [ ] CI builds both `amd64` and `arm64` digests for all 6 images
- [ ] `merge` job creates multi-arch manifests
- [ ] `docker buildx imagetools inspect huggingface/transformers-consistency` shows both platforms
- [ ] ARM Graviton runners can pull and run the images

🤖 Generated with [Claude Code](https://claude.com/claude-code)

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/28177332402) 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=46887)

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46887). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
auto_docstring prints [ERROR] doc-lint diagnostics to stdout at import time
Author: CalamitousFelicitousness
Pull request: no
Labels: name: bug

### System Info

- `transformers` version: 5.13.0.dev0
- Platform: Windows-11-10.0.26200-SP0
- Python version: 3.13.11
- PyTorch version (GPU?): 2.12.0+cu132 (CUDA 13.2, GPU available: yes)
- GPU: NVIDIA RTX 2000 Ada Generation Laptop GPU
- Accelerate version: 1.14.0
- Safetensors version: 0.8.0

### Who can help?

@stevhliu 

### Information

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

### Tasks

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

### Reproduction

from transformers.models.qwen2_5_vl import modeling_qwen2_5_vl  # noqa

Output:
```
[ERROR] `loss` is part of Qwen2_5_VLCausalLMOutputWithPast.__init__'s signature, but not documented. Make sure to add it to the docstring of the function in .../modeling_qwen2_5_vl.py.
[ERROR] `logits` is part of Qwen2_5_VLCausalLMOutputWithPast.__init__'s signature, but not documented. Make sure to add it to the docstring of the function in .../modeling_qwen2_5_vl.py.
```
Same for Qwen3VLCausalLMOutputWithPast and GlmImageCausalLMOutputWithPast (loss, logits).

Source: src/transformers/utils/auto_docstring.py:
- Message built (undocumented_parameters.append(...)), _process_regular_parameters,
- Emitted unconditionally: _process_parameters_section,
if len(undocumented_parameters) > 0:
    print("\n".join(undocumented_parameters))

### Expected behavior

Doc-lint diagnostics should not reach stdout during normal import. Either gate behind a docs-build/check flag, or route through logging at an appropriate level (dropping the literal [ERROR] prefix in favor of the log level).

Comments:
The log printing at import time is kinda expected and should be delayed to later after https://github.com/huggingface/transformers/pull/45056 is merged

Though it's interesting you see errors on missing args. I added recently support for merging docs from parent classes and re-checking now on `main` branch, I can't reproduce it. Could be related to python version and how dataclasses get resolved 🤔  
I am using python 3.10, but let me get 3.13 and check again

Ah it was fixed on main, I forgot that I merged it recently. Closing as resolved then
Documentation for the kernel API
Author: michaelbenayoun
Pull request: yes

# What does this PR do?

This PR provides the documentation for the big API changes and extension provided by #46339 

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46754). 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=46754)

I addressed your comments here: #46889
Kernel api doc, part 2
Author: michaelbenayoun
Pull request: yes

# What does this PR do?

Addresses comments from @vasqu in #46754.

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=46889)

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

This will depend on a new kernels version, see https://github.com/huggingface/kernels/pull/622

Updates to always use layer repos instead of function repos which also depends on kernels community PRs 
1. https://github.com/huggingface/kernels-community/pull/949
2. https://github.com/huggingface/kernels-community/pull/995
3. https://github.com/huggingface/kernels-community/pull/996 cc @Abdennacer-Badaoui 

TODOs
- bump respective kernels version (docs fail because kernels is installed?)

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

run-slow: afmoe, apertus, arcee, aria, bitnet, csm, cwm, dbrx, deepseek_ocr2, deepseek_v3, deepseek_v32, dia, diffllama, doge, dots1, emu3

**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46883)
[docs] AITER kernels
Author: stevhliu
Pull request: yes

add docs for #46268

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46871). 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=46871)
TST Run fast PEFT tests in normal CI
Author: BenjaminBossan
Pull request: yes

# What does this PR do?

PEFT tests were marked as slow, even though they're not slow. According to a comment there, this was probably only done to avoid running the tests before PEFT was released.

The `@slow` marker is now removed. All these tests use tiny models and on my machine, with warm HF cache, they passed in <12 sec on CPU without parallelism. It should thus be safe to assume that they are indeed fast enough. With these tests now running in normal CI, we should be able to prevent PEFT regressions in the future.

Note that the hotswapping tests are still marked as slow, as they partly require calling `torch.compile`.

## Code Agent Policy

- [x] No bots were harmed while writing this 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?
- [x] As discussed [here](https://github.com/huggingface/transformers/pull/45622#issuecomment-4332389211)
- [ ] 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?

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

@ydshieh It looks like all PEFT tests were [skipped](https://app.circleci.com/pipelines/gh/huggingface/transformers/173263/workflows/b7ac20b9-fed0-4e17-9196-9d30904c2f87/jobs/2290349?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-checks-link&utm_content=summary) because PEFT is not installed. Should PEFT be added as a test dependency?

Gentle ping @ydshieh 

Discussed with @ydshieh, we'll wait for the CI migration and then add the PEFT tests to a new job `tests_integrations`.
[docs] full disk offloading
Author: stevhliu
Pull request: yes

add docs for https://github.com/huggingface/transformers/pull/46749

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=46893)

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46893). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Inconsistent type annotation in `EvalPrediction`
Author: pietrolesci
Pull request: no

https://github.com/huggingface/transformers/blob/052e652d6d53c2b26ffde87e039b723949a53493/src/transformers/trainer.py#L4211

Hi there,

I am experimenting with the Trainer and noticed a potentially inconsistent type annotation for the fields in `EvalPrediction`. In particular, when the `batch_eval_metrics` is True the tensors are not converted to numpy arrays before being stored into the `EvalPrediction` dataclass and, more importantly, being used by the `compute_metrics` function. Imho this behaviour is quite convenient, however, it should perhaps be documented. Hopefully, this is useful.

Best,
Pietro

Comments:
Hi @pietrolesci 

I'd be interested in working on this.

From my reading, when `batch_eval_metrics=True`, `EvalPrediction` can receive tensors directly instead of NumPy arrays before being passed to `compute_metrics`. This seems to create a mismatch with the current type annotations and expected API contract.

One possible approach would be to update the `EvalPrediction` type annotations (and related documentation) to reflect that both tensors and NumPy arrays may be passed in this mode. Alternatively, if NumPy arrays are the intended contract, we could enforce the conversion before constructing `EvalPrediction`.

My inclination would be to first confirm the intended behavior and then align the annotations/documentation accordingly, along with tests covering the `batch_eval_metrics=True` path.

Happy to take this on if that direction makes sense.


Hi @pietrolesci 
 I'd like to investigate this issue . I would verify the intended behavior of  `EvalPrediction` when `batch_eval_metrics=True` and see if this is supposed to be addressed by type annotations/documentation or by enforcing a consistent conversion path. If everything looks straightforward, I'd be happy to open a PR.


Hi! I’m interested in investigating this issue as well.

From the discussion, it seems that when `batch_eval_metrics=True`, `EvalPrediction` may receive tensors directly instead of NumPy arrays before being passed to `compute_metrics`, which can make the current type annotations misleading.

I’d like to inspect the implementation and documentation to better understand the intended behavior and, if appropriate, submit a small documentation or type-annotation fix.


This was an interesting issue to investigate. I traced the evaluation flow for batch_eval_metrics=True and found that predictions, label_ids, and losses are passed to EvalPrediction as torch.Tensors before being converted to NumPy arrays, while the current annotations and documentation only mention np.ndarray. I've opened a PR to update the annotations and documentation accordingly
Update EvalPrediction annotations for batch_eval_metrics
Author: praful-srinivasan-027
Pull request: yes

# What does this PR do?

Fixes #46656.

This PR updates the `EvalPrediction` type annotations and documentation to reflect the runtime behavior when `batch_eval_metrics=True`.

In this code path, `predictions`, `label_ids`, and `losses` may be passed to `EvalPrediction` as `torch.Tensor`s before being converted to NumPy arrays. However, the current annotations and documentation only specify `np.ndarray`.

This PR updates the affected type annotations and documentation to include `torch.Tensor`, making them consistent with the existing runtime behavior. `inputs` is left unchanged since it represents the batch yielded by the dataloader and is outside the scope of this issue.


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=46896)
Fix GatedDeltaNet torch fallback prefill vs decode divergence (#46190)
Author: Aravind-11
Pull request: yes
Labels: name: Code agent slop

## Summary

Fixes [#46190](https://github.com/huggingface/transformers/issues/46190): large logit divergence (~0.125 max abs) on Qwen3.5 between full-sequence forward (`use_cache=False`) and prefill+decode with cache, when using the pure-torch GatedDeltaNet path (no `fla` / `causal-conv1d` / `mamba-ssm`).

### Root cause

`torch_chunk_gated_delta_rule` zero-padded incomplete final chunks to `chunk_size=64`. Those pad positions still updated the recurrent state. Because pad counts differ for sequence length `T` vs `T-1`:

| Call | Real tokens | Pad to 64 | State sees |
|------|-------------|-----------|------------|
| Full forward | T | 64-T pads | T + pads |
| Prefill | T-1 | 64-(T-1) pads | T-1 + different pads |

Decode then runs `torch_recurrent_gated_delta_rule` for the last token with a state that does not match the full-forward path → systematic drift that accumulates across hybrid GDA layers.

This matches the reporter's environment (torch fallback only) and the fact that fp32 does not help (not a precision issue).

### Fix

Make the pure-torch `torch_chunk_gated_delta_rule` delegate to `torch_recurrent_gated_delta_rule` so multi-token prefill and single-token decode use the same formulation. Full forward and prefill+decode are then mathematically aligned.

When FLA is installed, `chunk_gated_delta_rule` / `fused_recurrent_gated_delta_rule` still come from the optimized kernels (unchanged).

### Files

- `qwen3_next/modular_qwen3_next.py` + `modeling_qwen3_next.py`
- `qwen3_5/modeling_qwen3_5.py`
- `qwen3_5_moe/modeling_qwen3_5_moe.py`
- `olmo_hybrid/modeling_olmo_hybrid.py`

### Trade-off

Torch-only prefill becomes O(T) sequential instead of chunk-parallel. That path is already the slow fallback; install FLA for production throughput. Correctness over a silent ~0.125 logit error is the priority here.

## Test plan

- [ ] Repro from #46190 on `Qwen/Qwen3.5-0.8B` without FLA:
  ```python
  # full vs prefill+decode max abs logit diff should drop from ~1e-1 to ~1e-4 or better
  ```
- [ ] Same with FLA installed (optional): behavior unchanged from main (kernel path)
- [ ] Sanity: `Qwen3Next` / MoE / Olmo hybrid still import and run a short generate

Fixes #46190

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

run-slow: olmo_hybrid, qwen3_5, qwen3_5_moe, qwen3_next

**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46873)
Add SAM 3.1 to Transformers
Author: yonigozlan
Pull request: yes
Labels: name: New model

# What does this PR do?

First draft for SAM3.1 model.

Current state:
- Sam31TrackerVideoModel seems to be fully working prediction quality wise, but could use some polishing in the code, although modular is already doing some heavy lifting.
- Sam31VideoModel is mostly working, but there are still tiny differences with the original implementation that compound over time. Not ready quality wise and will need more investigating to understand what's going wrong compared to the original implementation

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

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

run-slow: auto, sam3, sam3_tracker_video, sam3_video

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=46128&sha=10412e

is this PR stale or is it still being worked on?
Fix path traversal in sharded-checkpoint loader via the index weight_map
Author: LinZiyuu
Pull request: yes

`get_checkpoint_shard_files` reads the shard filenames from the model repo's untrusted index file (`model.safetensors.index.json` / `pytorch_model.bin.index.json`) `weight_map`, and for a **local** model directory joins them onto the directory with no containment check:

```python
shard_filenames = sorted(set(index["weight_map"].values()))
...
if os.path.isdir(pretrained_model_name_or_path):
    shard_filenames = [os.path.join(pretrained_model_name_or_path, subfolder, f) for f in shard_filenames]
```

A `weight_map` value such as `"../../x.safetensors"` or an absolute path escapes the model directory, so loading a crafted local model with `from_pretrained` opens/reads a file from elsewhere on the victim's filesystem (path traversal, CWE-22). Loading by Hub id is unaffected — those go through `cached_files`/`hf_hub_download`, which reject `..`.

The fix verifies each resolved shard path stays inside the model directory before returning it, allowing files in subdirectories but rejecting `..`/absolute escapes. Adds regression tests.

This is a sibling of the Bark (#46237), OneFormer (#46270) and chat-template (#46191) path traversals — the same trust-boundary mistake (an untrusted repo value used verbatim as a path), in the shared checkpoint loader.

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

## Who can review?

- model loading (from pretrained, etc): @CyrilVallez

Comments:
View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=46281&sha=0db9ba
PPFormulaNet training-loss double-shift: trains against labels[..., 1:] instead of labels
Author: OmkumarSolanki
Pull request: no

### System Info

- `transformers` version: 5.13.0.dev0 (main, commit `c96378c413`)
- Platform: macOS, Python 3.11 (code-level bug, no specific hardware required)

### Who can help?

@yonigozlan @zucchini-nlp (PPFormulaNet / Florence2 area)

### Description

`PPFormulaNetForConditionalGeneration.forward` builds `decoder_input_ids` by right-shifting the target with `shift_tokens_right` (`modular_pp_formulanet.py:386`), then computes the training loss with `self.loss_function` (which maps to `ForCausalLMLoss`). `ForCausalLMLoss` shifts the labels a **second** time (`labels[..., 1:]`, `loss/loss_utils.py:24-25`), so the model trains against `labels[..., 1:]` instead of `labels` — an off-by-one in the training loss.

This is the same class of bug that was fixed for Moonshine in #46784 (and is being fixed for CohereASR / Florence2). PPFormulaNet right-shifts `input_ids` rather than `labels`, but the effect is identical when `input_ids == labels` — the standard encoder-decoder training setup, and exactly what the model's own test inputs use (`input_ids` is set equal to the decoder target).

### Reproduction

```python
import torch
from transformers import PPFormulaNetConfig, PPFormulaNetForConditionalGeneration

vision_config = {
    "image_size": 768, "patch_size": 16, "hidden_size": 48, "windows_size": 14,
    "num_hidden_layers": 1, "output_channels": 16, "num_attention_heads": 2,
    "global_attn_indexes": [1, 1, 1, 1], "mlp_dim": 1,
    "post_conv_in_channels": 16, "post_conv_mid_channels": 16,
    "post_conv_out_channels": 16, "decoder_hidden_size": 48,
}
text_config = {"decoder_ffn_dim": 16, "decoder_layers": 1, "d_model": 48, "vocab_size": 99}
config = PPFormulaNetConfig(text_config=text_config, vision_config=vision_config, num_hidden_layers=1)

model = PPFormulaNetForConditionalGeneration(config).eval()
V = config.text_config.vocab_size

torch.manual_seed(0)
target = torch.tensor([[5, 11, 23, 7, 42, 2]])     # input_ids == labels == decoder target
pixel_values = torch.rand(1, 3, 768, 768)

with torch.no_grad():
    out = model(pixel_values=pixel_values, input_ids=target, labels=target)

aligned = torch.nn.functional.cross_entropy(out.logits.reshape(-1, V), target.reshape(-1))
shifted = torch.nn.functional.cross_entropy(out.logits[..., :-1, :].reshape(-1, V), target[..., 1:].reshape(-1))

print("model loss      :", out.loss.item())   # 4.612360
print("CE vs labels    :", aligned.item())    # 4.542673  (correct)
print("CE vs labels[1:] :", shifted.item())   # 4.612360  (what the model actually computes)
```

The model loss matches the double-shifted CE, not the aligned CE.

### Expected behavior

Loss should be computed directly against `labels` with a plain `CrossEntropyLoss` (matching `WhisperForConditionalGeneration`, `BartForConditionalGeneration`, and the fixed Moonshine), with no second shift. Logits and `generate()` are unchanged, and `-100` stays ignored.


Comments:
call transformers-ci in a nightly run
Author: tarekziade
Pull request: yes

# What does this PR do?

Adds a nighly job that computes integration tests errors and call Serge to generate fixes in PRs

Comments:
linked PR https://github.com/huggingface/transformers-ci/pull/3


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

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