noamaanMulla-03/transformers-issues huggingface dataset:
[CI] Fix artifact download path in self-comment-ci workflow
Author: ydshieh
Pull request: yes

## What does this PR do?

Fixes the artifact download step in `self-comment-ci.yml` where files were landing in the wrong directory, causing the model/quantization CI report steps to always print \"No report found\".

### Root cause

The original step used a glob pattern with `merge-multiple: false`:
```yaml
pattern: new_failures_with_bad_commit_{run_models_gpu,run_quantization_torch_gpu}
path: ./new_failures
```

When only **one** of the two artifacts exists (e.g. the quantization artifact is absent), `actions/download-artifact` downloads the files directly into `./new_failures/` instead of into a named subdirectory. So instead of:
```
./new_failures/new_failures_with_bad_commit_run_models_gpu/new_failures_with_bad_commit.json
```
the files ended up at:
```
./new_failures/new_failures_with_bad_commit.json
```

### Fix

Split into two separate download steps, each using `name:` (not `pattern:`) with an explicit subdirectory as `path:`, and `continue-on-error: true` so the workflow doesn't fail when an artifact doesn't exist (e.g. quantization tests were skipped):

```yaml
- name: Download model CI new failures artifact
  uses: actions/download-artifact@...
  with:
    name: new_failures_with_bad_commit_run_models_gpu
    path: ./new_failures/new_failures_with_bad_commit_run_models_gpu
  continue-on-error: true

- name: Download quantization CI new failures artifact
  uses: actions/download-artifact@...
  with:
    name: new_failures_with_bad_commit_run_quantization_torch_gpu
    path: ./new_failures/new_failures_with_bad_commit_run_quantization_torch_gpu
  continue-on-error: true
```

## Before submitting
- [x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://huggingface.co/docs/transformers/contributing) and the [Pull Request](https://huggingface.co/docs/transformers/pr_checks) checks?

## Who can review?

@ydshieh (CIs)

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46769). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix several bugs in `cache_implementation=static`
Author: dacorvo
Pull request: yes

# What does this PR do?

Static-cache fixes for generate(), one commit each:

- Fix chunked-prefill recompilation: the lazy-init branch bakes the cache init into the first compiled graph, forcing a second graph; init eagerly instead (#46421).
- Honor cache_config["max_cache_len"] on the static path so the cache is sized for the worst case across calls (#46424).
- Make Cache.early_initialization skip linear-attention layers (it corrupted their conv/recurrent shapes → RuntimeError) (#46439).
- Let create_masks_for_generate defer to the model for layer types with no mask function, instead of KeyError: 'linear_attention' (#46441).
- Make Cache.max_cache_len skip linear-attention layers (the static-cache reuse check AttributeError'd on hybrids).

Together these make static-cache + chunked-prefill generation work without recompiles for plain (Llama) and hybrid linear-attention (Qwen3.5) models. Each commit has a regression test.

- [X] I confirm that this is not a pure code agent PR.

## Before submitting
- [X] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [X] 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.

@ArthurZucker @Cyrilvallez @vasqu

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

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=46446&sha=6f39ad
Fix equality-vs-assignment bug in GptqHfQuantizer.update_device_map
Author: gapsong
Pull request: yes

Fixes a typo in `GptqHfQuantizer.update_device_map` where an equality comparison (`==`) was used instead of an assignment (`=`). Due to this, `device_map` was never updated to CUDA when using `auto-gptq` (which does not support CPU), leaving the model on CPU contrary to the intent expressed in the comment.

- File: [src/transformers/quantizers/quantizer_gptq.py](https://github.com/huggingface/transformers/blob/e54defcfc265a1cc4f62edbf977747a0a443c812/src/transformers/quantizers/quantizer_gptq.py)
- Function: `GptqHfQuantizer.update_device_map`

Before:
```python
if not is_gptqmodel_available() and device_map in ("cpu", {"": torch.device("cpu")}):
    device_map == {"": 0}
```

After:
```python
if not is_gptqmodel_available() and device_map in ("cpu", {"": torch.device("cpu")}):
    device_map = {"": 0}
```

This change makes the code match the intended behavior: when `gptqmodel` is not available and the model would otherwise be placed on CPU, move to CUDA device map (`{"": 0}`).

## Who can review?

- quantization (bitsandbytes, autogpt, gptqmodel): @SunMarc @MekkCyber

Anyone in the community is also welcome to review.

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

run-slow: gptq

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_41304). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Add Nemotron ASR Streaming
Author: eustlb
Pull request: yes
Labels: name: New model

name: Audio

# What does this PR do?

Should be merged before: #46331

original checkpoints:
- [nvidia/nemotron-speech-streaming-en-0.6b](https://huggingface.co/nvidia/nemotron-speech-streaming-en-0.6b)


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

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=46332&sha=53e68c

@run-slow: nemotron_asr_streaming

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/27775387305) for the exact violations.

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

run-slow: nemotron_asr_streaming

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

slow test passing locally (run-slow not working for some reason)! Ready to merge 🎉

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

run-slow: auto, nemotron_asr_streaming, voxtral_realtime
docs: move SmolLM3 to Text models category in _toctree.yml
Author: yyouretoast
Pull request: yes

# What does this PR do?

This PR moves the `SmolLM3` documentation entry from the `Multimodal` section to its correct alphabetical position under the `Text models` section in `_toctree.yml`. 

Fixes huggingface/hub-docs#2031 (moved from hub-docs repository).

- [x] I confirm that this is not a pure code agent PR.

## Before submitting
- [x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://huggingface.co/docs/transformers/contributing) and the [Pull Request](https://huggingface.co/docs/transformers/pr_checks) checks?
- [x] Was this discussed/approved via a Github issue or the forum? Please add a link to it if that's the case. (Approved in huggingface/hub-docs#2031)
- [x] Did you make sure to update the documentation with your changes according to the guidelines?

## Who can review?

Tagging @stevhliu for documentation review.

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

Thank you for the review and approval, Julien!

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46770). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Add VideoPrism
Author: MHRDYN7
Pull request: no
Labels: name: New model

### Model description

I'd like to contribute the VideoPrism model by google deepmind. The code base (written in flax) was made public in June and the base model weights alone has 2.7k downloads on [HF hub](https://huggingface.co/google/videoprism-base-f16r288) with almost no support except for the original repo. There are two models, a foundational video model and a video-text model, with base and large sizes.

Why add the model
* They claim that the model "achieves state-of-the-art performance on 31 out of 33 public video understanding benchmarks using a single frozen model."
* The architecture is unique with a spatial encoder layer followed by a temporal encoder layer (not fused spatio-temporal encoders) with no cls token. This architectures was introduced in the [VIVIT paper](https://arxiv.org/abs/2103.15691) but the HF VIVIT model implements only one of the four architectures proposed in that paper even though the weight for this architecture was released back then.

What the model lacks
* The VideoPrism [paper](https://arxiv.org/abs/2402.13217) was released in feb 2024, so it is old and therefore the architecture does not include modern day components like rotary positional embeddings (used in vjepa2) or GLU.
*  The foundational video model does not come with the head weights and they don't even plan to release those and that's why we'll need to train the final layer on something like the kinetics-400 dataset for classification model.

### Open source status

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

### Provide useful links for the implementation

Paper link: https://arxiv.org/abs/2402.13217
Repo link: https://github.com/google-deepmind/videoprism
checkpoint: [video model](https://huggingface.co/google/videoprism-base-f16r288), [video-text model](https://huggingface.co/google/videoprism-lvt-base-f16r288)

@qubvel @NielsRogge I've already converted the base model's flax implementation to HF and got the exact logits for the forward pass. I'll go ahead with the rest if I get the green light for the contribution. 

Comments:
you may take a look at the implementation in the draft pr above

Sounds good! Ideally modular can be leveraged: https://huggingface.co/docs/transformers/en/modular_transformers

Sure, I've used the modular approach inheriting classes from vivit.
[RT-DETRv2] Fix MPS crash in build_2d_sinusoidal_position_embedding (float64 → dtype)
Author: Sahith59
Pull request: yes

**Fixes #46159**

While tracing the MPS crash in **RT-DETRv2**, I noticed the same **build_2d_sinusoidal_position_embedding** function with the same **torch.float64** issue exists across several other models too **— rt_detr, d_fine, deimv2,** **pp_doclayout_v2, pp_doclayout_v3, aimv2, and vit_mae**. They all share essentially the same copy of this function, and they all crash on MPS for the same reason.

The function already accepts a dtype parameter (defaults to float32), but the body completely ignores it, every tensor is created with **dtype=torch.float64** hardcoded. On CUDA this is fine, just slightly wasteful. On MPS it crashes immediately because Apple's Metal framework doesn't support float64 at all. The **.to(dtype)** at the end never runs because the crash happens earlier, at tensor creation.

Also updated the docstring which said "frequency arithmetic uses float64 internally", that was the original intention but clearly wasn't what the dtype param was supposed to communicate.

Applied the fix at the root in **vit_mae/modular_vit_mae.py** and across all downstream copies, then re-ran the modular converter so rt_detr_v2 regenerates cleanly and the consistency check passes.

**_pytest tests/models/rt_detr_v2/ tests/models/rt_detr/ tests/models/vit_mae/ tests/models/aimv2/ -x -q -k "not slow"_**

****Also confirmed MPS inference works locally on M-series after the change.**

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

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

**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46780)
Add lfm2.5 audio
Author: MHRDYN7
Pull request: yes

Add support for lfm 2/2.5 audio models. (closes #43909)

Comments:
cc @eustlb

I'll wait for the PR to be undrafted to review 🤗 @MHRDYN7 feel free to ping me

@MHRDYN7 , are you still working on this? I’d love to work on it.


Yes actually. Had to shift focus on another model so haven't pushed my changes

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/27898831295) for the exact violations.

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

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

run-slow: auto, lfm2_audio
Fix secondary rate limit when downloading artifacts in slack report
Author: ydshieh
Pull request: yes

## Summary

- Switches `download-artifact` to a forked version ([ydshieh/download-artifact@rate_limit_friendly](https://github.com/ydshieh/download-artifact/pull/1)) that adds a `chunk-delay` input
- Sets `chunk-delay: 1000` (1 second between each batch of 5 downloads) to avoid GitHub secondary rate limit errors when downloading ~1000 test report artifacts

## Context

The slack reporting job downloads all artifacts from a workflow run (can be ~1000). Without throttling, all downloads fire in rapid succession and hit GitHub's secondary rate limit (`RequestError: You have exceeded a secondary rate limit`). The forked action fixes this by deferring promise creation so the delay is correctly applied between batches.

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46796). 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=46796)
Made SAM3 to return loss in outputs
Author: ash01825
Pull request: yes

# What does this PR do?
Fixes #42659

I have added the loss function for sam3 so now it gives loss as output when input with labels. Created a new Hungarianmatcher same as BinaryHungarianMatcherV2(https://github.com/facebookresearch/sam3/blob/main/sam3/train/matcher.py) which is the one currently used by sam3. Added loss functions and outputs include now auxiliary output, loss and loss_dict. Loss weights can be configured as per needs. Have added necessary tests and tested for them.


- [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.
- [x] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [x] Did you write any new necessary tests?


## Who can review?

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.


@molbap  
@yonigozlan 

Comments:
thanks for the PR @ash01825 ! Do you mind running `make style && make fix-repo` in a local install to make CI initial checks happy? then I'll take a look

Hey @molbap  I ran `make style && make fix-repo` but it's leading to changes which aren't related to the issue and like in files I haven't even touched.
I kept the change which was related.


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

run-slow: sam3, sam3_lite_text

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

@molbap @yonigozlan 
Sorry it was my issue I had updated ruff version being used.
The errors being thrown was because sam3_lite_text builds itself on the sam3 so had to add the loss for that too. 
Now it computes loss for sam3_lite_text as well. Also added configuration attributes for both sam3 and sam3_lite_text as we have an option for to edit loss weights.

Hey @molbap I've passed the tests. Please review it when possible. Thanks!
Processing Utils: honor pre-built sub-processor kwargs in from_pretrained
Author: javierdejesusda
Pull request: yes

## What does this PR do?

Addresses @ArthurZucker's follow-up on #44987. When a caller passes a pre-built sub-processor to `AutoProcessor.from_pretrained` — e.g. `tokenizer=tok` or `bpe_tokenizer=tok` — the instance is now used directly instead of being silently forwarded into the sub-loader calls.

Exact attribute names always take precedence (`bpe_tokenizer=`). For processors with a single sub-processor of a given modality, the canonical modality name (`tokenizer=`) is also accepted as an alias — this matches the reproducer in the issue comment, where the remote `UniversalActionProcessor` takes `bpe_tokenizer` but the caller passes `tokenizer=`.

The OP's zero-kwarg reproducer (`AutoProcessor.from_pretrained("physical-intelligence/fast", trust_remote_code=True)`) is a separate hub repo layout issue and is not addressed here.

## Before submitting

- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request)?
- [x] Did you write any new necessary tests?

## Who can review?

cc @ArthurZucker @itazap

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

run-slow: auto

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

@ArthurZucker gentle ping, would appreciate a review when you have time.
Add minimax m3vl
Author: ArthurZucker
Pull request: yes
Labels: name: New model

# What does this PR do?


Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46600). 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, deepseek_v4, minimax_m3_vl, finegrained_fp8

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

> ⚠️ **Code quality check failed** — all test jobs were skipped. Fix the code quality issues and push again to run tests.

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=46600&sha=c6615c
[WIP] Support custom kernels for processing ops
Author: molbap
Pull request: yes

# What does this PR do?

TL;DR Preprocessing and postprocessing ops can be offloaded to Hub kernels the same way model layers currently are. This PR allows this and goes with a first simple kernel that is common to many image processors.

`use_kernels=True` swaps a processor op for a registered Hub kernel and falls back to the default implementation when none applies. So custom or hard-to-vectorize ops (beyond resize or normalize: patchify, NMS, mask decoding, ...) can move onto the GPU without rewriting the processor or the call site. 

However the adapter is uglier than for modeling components, mainly because there's no same-signature forward to swap and no kernelize pass over processors. Open to ideas here!

I pushed a fast image processors' resize + normalize that is automatic for processors using the base fast-processing path others fall back and can opt in later. The kernel batches the resize over a ragged set of images and folds rescale and normalize into the same pass.

```py
from transformers import AutoImageProcessor

processor = AutoImageProcessor.from_pretrained("google/siglip2-base-patch16-224", use_kernels=True)
pixel_values = processor(images, return_tensors="pt")["pixel_values"]
```

For vision-language models the image processor is wrapped in a processor, so the flag passes through [`AutoProcessor`] to the inner image processor.

```py
from transformers import AutoProcessor

processor = AutoProcessor.from_pretrained("google/gemma-3-4b-it", use_kernels=True)
inputs = processor(text=prompt, images=images, return_tensors="pt")
```

Some benchmarks for processors of vision models showing the speedup:

```md
processor() resize+normalize, use_kernels off -> on:
siglip2-base-patch16-224     3.92 -> 1.30 ms   3.0x   pixΔ 3.9e-3
paligemma2-3b-pt-224         4.26 -> 1.36 ms   3.1x   pixΔ 3.9e-3
clip-vit-base-patch32        7.30 -> 1.41 ms   5.2x   pixΔ 1.8e-2
dinov2-small                 7.26 -> 1.42 ms   5.1x   pixΔ 2.5e-1


standalone resize stage (siglip-so400m, bicubic+AA):
torchvision eager loop   2.95 ms
torch.compile (dynamic)  5.65 ms   (slower; ~2.6s warmup)
fused triton (2D)       11.53 ms
separable triton        1.37 ms    -> 2.9x the real processor (3.96 ms)
```

Need to move the kernel from `Molbap/<kernel_name>` and open this to the community. Feedback welcome :) 


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