noamaanMulla-03/transformers-issues huggingface dataset:
[Model Request] Add EUPE (Efficient Universal Perception Encoder) by Meta AI
Author: forensicmike
Pull request: no
Labels: name: New model

### Model description

I would like to request adding support for EUPE (Efficient Universal Perception Encoder), a recent vision backbone released by Meta AI.

Paper: https://arxiv.org/abs/2603.22387
Code: https://github.com/facebookresearch/eupe

EUPE is a multi-purpose vision encoder trained via distillation from multiple domain-specific foundation models into a unified representation. It is designed to be efficient (edge-friendly), general-purpose (strong across diverse downstream tasks), and competitive with specialized encoders of similar size.

The model family includes both Vision Transformers (ViT-T/S/B, patch size 16) and ConvNeXt backbones (T/S/B) (see model weights on huggingface at [facebook/eupe](https://huggingface.co/collections/facebook/eupe).

I would be willing to work on a PR for this model, including: model implementation (ViT + ConvNeXt variants), weight conversion script, tests and docs. Happy to align with maintainers on: scope (e.g., start with ViT only), naming conventions, integration approach.

Note that the non-commmercial research license for these models mirrors other Meta model releases (e.g. DINO, SAM) which already have implementations in the library.

### Open source status

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

### Provide useful links for the implementation

https://github.com/facebookresearch/eupe
https://huggingface.co/facebook/EUPE-ViT-B
@zcck3rn3l


Comments:
cc @nielsrogge @molbap

Could I work on this? 

@Rocketknight1 @NielsRogge @molbap  Since this is a DINOv3 behind the scenes what is actually needed for the integration? 
are the modular_<model>.py, modeling_<model>.py needed, image_processing_<model>.py, and configuration_<model>.py needed?

i have looked into it and some things are different but only for the training case and are covered by DINOv3ViTConfig or are remnants from training like some projection matrices (which only matter if you use the same teachers on the same tasks, else you init your own)

i have the integration script based on Meta's uploaded weights should i move one with a PR containing only a eupe/convert_eupe_vit_to_hf.py ?

I think in this case we should probably just modify the DINOv3 conversion script to work for EUPE checkpoints too! If they're really identical architectures that should work fine

Done here https://github.com/huggingface/transformers/pull/46691 to track the conversion script, and opened hub PRs here:

https://huggingface.co/facebook/EUPE-ViT-T/discussions/1
https://huggingface.co/facebook/EUPE-ViT-S/discussions/1
https://huggingface.co/facebook/EUPE-ViT-B/discussions/1
https://huggingface.co/facebook/EUPE-ConvNeXt-T/discussions/1
https://huggingface.co/facebook/EUPE-ConvNeXt-S/discussions/1
https://huggingface.co/facebook/EUPE-ConvNeXt-B/discussions/1
Add SWA+sink option to Granite models
Author: daviswer
Pull request: no
Labels: name: New model

### Model description

For upcoming Granite model release (4.5) we would like to add support for sliding window attention with a sink token. I think it may be easier to add as a flag in existing models, rather than adding more Granite model classes (granitemoesharedswa seems gratuitous), though we'll need to ensure no effect on backward compatibility in that case. 

We have a code implementation and model weights, and I'll open a PR in the next couple days. This issue is essentially just advance notice. 

@ArthurZucker 

### Open source status

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

### Provide useful links for the implementation

Implementation by @Bharat-Runwal as a separate model class is available [here](https://github.com/Bharat-Runwal/transformers/tree/granite-swa-model), though again it might make more sense to implement as optional through existing classes. 

Model weights are not available just yet, but they exist internally and will eventually appear [here](https://huggingface.co/ibm-research/granite-4.5-3b-pipecleaner-r260528a)

Comments:
Hey! 
This is never how we add support for new models 😉 
If your model has SWA + SINK its not longer granite. Its a new model with its new architecture !

Ah ok, good to know. That does simplify the process then. Thanks!
Tp param level
Author: 3outeille
Pull request: yes

Done:
	-  handling sparse + dense in the sp_plan for models like qwen3_moe
	 - better tests to check ep/tp/sp path during forward/backward 
	 - Double check MoEExpertsParallel
go from module level to param level ("layers.*.mlp.experts.gate_up_proj": "grouped_gemm", "layers.*.mlp.experts.down_proj": "grouped_gemm", "layers.*.mlp.experts": "moe_experts_allreduce",)
	- Double check ep_router => is it the same as main and Amine
	- fixing ep_backward test
	- sp + ep training / tp + ep inference

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

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

run-slow: afmoe, apertus, arcee, aria, bamba, bitnet, cohere, cohere2, cohere2_moe, csm, cwm, dbrx, deepseek_v2, deepseek_v3, deepseek_v32, deepseek_v4

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=46290&sha=f00563
Docs: load weights from S3-compatible object storage (Backblaze B2)
Author: goanpeca
Pull request: yes

Adds a short subsection to the installation docs showing how to read model weights and datasets from S3-compatible object storage. It maps a Backblaze B2 application key onto the standard AWS environment variables, sets the endpoint via `AWS_ENDPOINT_URL`, and points `s3fs` and `datasets` `storage_options` at the bucket. The same configuration works against AWS S3 and Backblaze B2.

This is documentation only. Transformers loads models through `huggingface_hub`, so there is no pluggable object-storage backend to change; the section documents the standard download-then-load pattern.

Disclosure: this change was prepared with the assistance of an AI coding tool. I reviewed it, verified the referenced APIs and environment variables against the current source, and take ownership of the contribution. Happy to coordinate on a tracking issue first if the maintainers prefer.


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=46702)
Add DistributedConfig for 2D parallelism (TP + FSDP)
Author: 3outeille
Pull request: yes

## Summary
- Introduces/refactors `DistributedConfig` for tensor-parallel and FSDP settings
- Wires distributed config into `PretrainedConfig` and model loading
- Adds unit tests for `DistributedConfig` serialization and defaults


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

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=46704&sha=799ac9
Add native FSDP2 module and import migration
Author: 3outeille
Pull request: yes

## Summary
- Add `src/transformers/distributed/fsdp.py` with FSDP2 wrapping (`apply_fully_shard_data_parallel`), plan expansion/verification, and FSDP1/2 detection
- Keep `integrations/fsdp.py` as a backward-compatible re-export shim
- Migrate core imports in `accelerate.py`, `trainer.py`, `trainer_seq2seq.py`, and `generation/utils.py`
- Export `is_fsdp_enabled`, `is_fsdp_managed_module`, `verify_fsdp_plan` from `transformers.distributed`
- Add unit tests in `tests/test_distributed_fsdp.py`

**Stacks on:** #46705 

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

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

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46706). 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=46706&sha=22d4b5
Update GLM-5.2 docs
Author: Dovis01
Pull request: yes

### Docs Update
Update the official docs for a comprehensive overview of the GLM-5 series, including GLM-5, GLM-5.1, and the new GLM-5.2. 

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=46703)
Multi-gpu loading when the whole backbone is tied
Author: zucchini-nlp
Pull request: yes

Fixes https://github.com/huggingface/transformers/issues/46566. The whole model was being loaded on disk

The provided script fails in multi-gpu setup, even on DGX tho the model can perfectly fir on a single GPU. The reason was in how `module_size_with_ties` is computed: it adds the whole tied module size while iterating over parameters. When a single module has several tied params as in DiffusionGemma, we end up with `module_size_with_ties = 30k GB` 😭  I dont' know why we were adding module size and not param size, leaving it for you to judge

Another issue, when module (`model.encoder`) cannot fit on device with tied params and fits without tied params, we try to split the tied children (split `model.encoder.layers.0` into smaller unites).  Ideally we have to try and split current module (split `model.encoder` first if possible). In case of Gemma, we can't split each tied layer and thus we just skip this device entirely until we reach disk.

I removed a condition so we fallback to splitting current module always as long as it isn't in `no_split_modules`


Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46625). 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=46625)
ci: grant pull-requests:write to the security gate caller
Author: ydshieh
Pull request: yes

## What does this PR do?

The PR CI security gate reusable workflow (`transformers-test-ci`) was recently updated to post a PR comment when it blocks automatic CI approval (allowlist violation or new Bandit high-severity finding). That comment step requires `pull-requests: write`.

The reusable workflow already declares the permission, but a reusable workflow can only use permissions that the **caller** explicitly grants. The caller here (`pr-ci-security-gate.yml`) only declared `actions: write` and `contents: read`, causing a workflow validation failure:

> The workflow is requesting 'pull-requests: write', but is only allowed 'pull-requests: none'.

This PR adds `pull-requests: write` to the caller's `permissions` block. Since the caller uses `pull_request_target` (runs in the base repo context, not the fork), this permission is fully available and safe to grant.

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46715). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
chore: update pr-ci-security-gate.yml
Author: hf-security-analysis[bot]
Pull request: yes

Update `.github/workflows/pr-ci-security-gate.yml` workflow configuration.

cc @ydshieh

Closes huggingface/tracking-issues#833
<!--slack ts:1781690427.360629 channel:C0AJSP0D53L-->

Comments:
## CI Security Gate — automatic approval blocked

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

**Possible reasons:**
- A changed file is outside the allowed directories (`src/`, `tests/`, `docs/`, `utils/`) or has a disallowed extension (only `.py`, `.txt`, `.md` are permitted outside `tests/`)
- 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/27681046060) 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=46716)

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

### Feature request

Add the ability to specify a padding strategy when using `DataCollatorForLanguageModeling`

### Motivation

This is a minor QOL enhancement that makes the collator more consistent with others in the library. The main use case would probably be padding to max length to make memory usage more stable during training.

### Your contribution

I'll submit a PR in just a bit to add this :)

Comments:
Hi, May I contribute on this?
fix(sdpa): add MPS workarounds for bidirectional attention and value head dim bugs
Author: PINKIIILQWQ
Pull request: yes
Labels: name: Code agent slop

For PyTorch < 2.12, MPS SDPA integration mishandles value head dims that differ from query head dims.

- `v_head_dim < q_head_dim`: pad value to q_dim before SDPA, then slice output back to original v_dim.
- `v_head_dim == q_head_dim`: no-op.
- `v_head_dim > q_head_dim`: skip the padding workaround and warn, because negative padding would crop value and corrupt the output.

Includes coverage for all three cases.

Comments:
View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=46699&sha=9e9dff

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

### CI status

Three CI jobs are currently failing in this PR:

- **pipelines_torch** — on CircleCI
- **tests_processors** — on CircleCI  
- **tests_torch [shard 5/8]** — on GitHub Actions

The failure trace I checked points to `tests/models/paligemma/test_modeling_paligemma.py` (`AssertionError: Found non-zero attention weights for padding token`), which is outside this PR's touched files (`src/transformers/integrations/sdpa_attention.py` and `tests/test_sdpa_attention.py`). The SDPA changes are gated behind `_is_torch_greater_or_equal_than_2_12` and should have no effect on non-MPS PyTorch 2.12+ runs like these CI jobs.

Happy to re-run the failed shards if a maintainer confirms they are worth re-triggering.
[VITS] Un-skip test_model_forward
Author: blipbyte
Pull request: yes

  `VitsModelTest.test_model_forward` has been skipped since #26574 (Oct 2023, "[Tokenizers] Skip tests temporarily"). The `Need to fix this after #26538` reason is a stale typo -  #26538 is unrelated.

  Un-skipping it after replacing the hardcoded waveform length `624` with the architectural invariant `T_frames × ∏ upsample_rates`. The old constant was tied to one specific realization of the stochastic duration predictor and drifted across torch versions; the invariant matches the formula `VitsModel.forward` itself uses (modeling_vits.py:1391) to 
  derive `sequence_lengths` and catches HiFi-GAN upsampling regressions without depending on `T_frames` stability.

  **Tests**
  `pytest tests/models/vits/test_modeling_vits.py::VitsModelTest::test_model_forward -v` passes locally. `make check-code-quality` passes.

  **AI**
  Drafted with Claude. I reviewed every line and ran the repro locally. No existing issue or open PR.



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

run-slow: vits

run-slow: vits

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

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

models: ["models/vits"]
quantizations: []

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

### Commit Info
| Context | Commit | Description |
|---------|--------|-------------|
| RUN | [d4cfba6e](https://github.com/huggingface/transformers/commit/d4cfba6e884ae5900abadd6f72ac00f2f12b303a) | workflow commit (merge commit) |
| PR | [921f52bb](https://github.com/blipbyte/transformers/commit/921f52bb0d0e45830354fccbfad326782f13d8f5) | branch commit (from PR) |
| main | [595721c4](https://github.com/huggingface/transformers/commit/595721c44cb14db37fa504903e2edd5e9f0eba43) | 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/26881790038) for details.


cc @ydshieh @tarekziade for tests, and also because the slow test failed here and I don't know why :sweat_smile: 

`test_forward_fp16` failure is unrelated to this PR - it only un-skips `test_model_forward`.

This PR only un-skips `test_model_forward`. The `test_forward_fp16`
  failure is a separate pre-existing test, unrelated to this change.
  Could CI be re-run? cc @Rocketknight1
Laguna: support per-element output gating
Author: joerowell
Pull request: yes

# What does this PR do?

Laguna applies a softplus output gate after attention, whose granularity is set
by `config.gating`. The current implementation hardcodes the per-head case
(`g_proj` sized `num_heads`, gate broadcast over `head_dim`). This PR adds the
configurable per-element setting:

- `True` / `"per-head"`: one gate per head (`g_proj` output = `num_heads`).
- `"per-element"`: one gate per `(head, head_dim)` channel
  (`g_proj` output = `num_heads * head_dim`).

Without it, a config with `gating="per-element"` mismatches the `g_proj` weight
shape at load time.

## Changes

- Add `gating` (`bool | str`, default `True`) to `LagunaConfig`, with docstring.
- Branch `g_proj` allocation and the forward gate application on `config.gating`
  in `modular_laguna.py`; regenerate `modeling_laguna.py` and
  `configuration_laguna.py`.
- Add gating shape tests to `tests/models/laguna/test_modeling_laguna.py`.

The default (`gating=True`) behavior is unchanged, and the dispatch mirrors the
vLLM Laguna implementation. Per-element support is unit-tested at the model
level (g_proj allocation + a per-element forward pass).

## 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)?
- [x] Did you make sure to update the documentation with your changes? (config docstring)
- [x] Did you write any new necessary tests?

## Who can review?

Text-models / `modular` maintainers, I suppose. Laguna was added in #45673.

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

run-slow: laguna

run-slow: laguna

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

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

models: ["models/laguna"]
quantizations: []

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

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

### Commit Info
| Context | Commit | Description |
|---------|--------|-------------|
| RUN | [2b709214](https://github.com/huggingface/transformers/commit/2b7092145303b51b813beb36567acb825072dfac) | workflow commit (merge commit) |
| PR | [915c33ec](https://github.com/joerowell/transformers/commit/915c33ecc7c05674fe16c9c528f0303666d442e7) | branch commit (from PR) |
| main | [c8bdae17](https://github.com/huggingface/transformers/commit/c8bdae17e5fa5ae745fb57148117d3137b03896f) | base commit (on `main`) |

✅ No failing test specific to this PR 🎉 👏 !


The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46690). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix: reject Hub kernel repo patterns in attn_implementation loaded from config
Author: Snakinya
Pull request: yes

## Summary

Reject Hub kernel repository patterns (containing `/`) in the `attn_implementation` field when loaded from `config.json`. This prevents a malicious model config from silently triggering remote kernel code download and execution during `from_pretrained()` without `trust_remote_code=True`.

## Problem

When a model's `config.json` contains `"attn_implementation": "some-org/some-repo"`, the value is processed by `kwargs.pop()` at line 299 of `configuration_utils.py` and passed through the `_attn_implementation` property setter, which writes it to `_attn_implementation_internal`. During model initialization, `is_kernel()` matches the Hub repo pattern, and `get_kernel()` is called to download and execute kernel code — all without requiring `trust_remote_code=True`.

An attacker can exploit this by publishing a model with a crafted `config.json` to achieve remote code execution on any user who loads the model.

## Fix

Validate that `attn_implementation` values loaded from config do not contain `/` (the Hub repo pattern). This blocks kernel-style repo IDs from being injected via config while preserving all standard values (`eager`, `sdpa`, `flash_attention_2`, `flash_attention_3`).

Users can still set kernel implementations explicitly via `from_pretrained(attn_implementation=...)` as that code path in `modeling_utils.py` runs after config loading and is a deliberate user choice.

## Test plan

- [ ] Existing tests pass (standard `attn_implementation` values unaffected)
- [ ] `config.json` with `"attn_implementation": "some-org/some-kernel"` is rejected with warning
- [ ] `from_pretrained(attn_implementation="kernels-community/flash-attn")` still works (user-explicit)


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

Hey :wave: I'm closing this as this won't be a problem anymore with #46039, it will be rejected downstream by the kernels library then
[`Templates`] Update members
Author: vasqu
Pull request: yes

As per title

Comments:
## CI Security Gate — automatic approval blocked

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

**Possible reasons:**
- A changed file is outside the allowed directories (`src/`, `tests/`, `docs/`, `utils/`) or has a disallowed extension (only `.py`, `.txt`, `.md` are permitted outside `tests/`)
- 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/27691835055) 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=46720)

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