noamaanMulla-03/transformers-issues huggingface dataset:
Florence2 training-loss double-shift bug (same pattern as Moonshine #46784)
Author: sharmax-vikas
Pull request: no
Labels: name: bug

### System Info

- `transformers` version: 5.13.0.dev0 (main branch at commit dc5a497c18)
- - Platform: Windows
- - - Python version: 3.x
- - - - Using GPU: N/A (code-level bug, not runtime)

### Who can help?

@zucchini-nlp @yonigozlan

### Information

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

aIn `src/transformers/models/florence2/modular_florence2.py`, `Florence2ForConditionalGeneration.forward()` has a double-shift bug introduced in PR #40914:

1. Labels are shifted right via `shift_tokens_right()` (line 1588) to create `decoder_input_ids`
2. 2. Then `self.loss_function()` is called (line 1613), which maps to `ForCausalLMLoss`
3. 3. `ForCausalLMLoss` shifts labels again internally (`labels[..., 1:]` in `loss/loss_utils.py` line 63-64)
This means the model trains against `labels[..., 1:]` instead of `labels`. Same bug fixed in Moonshine PR #46784.

```python
# Buggy code:
loss = self.loss_function(logits=logits, labels=labels, vocab_size=self.config.text_config.vocab_size, **kwargs)

# Should be:
loss_fct = CrossEntropyLoss()
loss = loss_fct(logits.reshape(-1, self.config.text_config.vocab_size), labels.reshape(-1))
```

### Expected behavior

Training loss should be computed directly against `labels` without any additional shifting, since `shift_tokens_right()` already handles the decoder input alignment. This matches the behavior of Whisper, Bart, and the now-fixed Moonshine and CohereASR models. The fix should use `CrossEntropyLoss()` instead of `self.loss_function()`, as done in Moonshine PR #46784.

Comments:
[Olmo3] different RoPE per layer type
Author: zucchini-nlp
Pull request: yes

# What does this PR do?

Reverts back per layer-type RoPE in Olmo which was removed in https://github.com/huggingface/transformers/pull/39847


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

run-slow: olmo3, olmo_hybrid

run-slow: olmo3, olmo_hybrid

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

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

models: ["models/olmo3", "models/olmo_hybrid"]
quantizations: []

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

### Commit Info
| Context | Commit | Description |
|---------|--------|-------------|
| RUN | [de5cfa59](https://github.com/huggingface/transformers/commit/de5cfa59be58c5cc61de35279456ae9f60177e2a) | workflow commit (merge commit) |
| PR | [a6dfe8d0](https://github.com/zucchini-nlp/transformers/commit/a6dfe8d011d0acaa5eef7272004c60d8a1f4ac04) | branch commit (from PR) |
| main | [ed7d6c8d](https://github.com/huggingface/transformers/commit/ed7d6c8dbcc7a56b01fd23d7de58fb4731c394d8) | base commit (on `main`) |

✅ No failing test specific to this PR 🎉 👏 !


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

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

run-slow: olmo3, olmo_hybrid
Fix Gemma4 closed thinking block detection in serve
Author: JemmaUZH
Pull request: yes
Labels: name: Code agent slop

# What does this PR do?

Fixes #46561.

This PR fixes Gemma 4 reasoning detection in `transformers serve` when thinking is disabled.

Gemma 4 can render an empty thinking block that is immediately closed in the prompt. The previous `_starts_in_thinking` logic only checked whether the prompt ended near the thinking start token, so it could incorrectly treat the following generated text as `reasoning_content`.

This change passes the thinking end token into `_starts_in_thinking` and returns `False` when the prompt already ends with the thinking end token.

## Tests

```bash
.venv/bin/python -m pytest tests/cli/test_serve.py::TestReasoningUtils::test_starts_in_thinking_rejects_already_closed_block -q
ruff check src/transformers/cli/serving/utils.py tests/cli/test_serve.py
ruff format --check src/transformers/cli/serving/utils.py tests/cli/test_serve.py
git diff --check

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

As I said in the original issue, we'll be refactoring this with the new response templates, so I'm not sure we want to merge this right now!
fix(deepspeed): chunk ZeRO-3 missing-key param gather to avoid OOM
Author: itxsamad1
Pull request: yes
Labels: name: Code agent slop

## Summary
- Fixes OOM during `from_pretrained` under DeepSpeed ZeRO-3 when many missing parameters need initialization (e.g. large sparse MoE models like MiniMax-M3).
- Instead of gathering all uninitialized parameters in one `GatheredParameters` context, gather them in bounded chunks so peak rank-0 memory stays bounded.

## Context
When loading large sparse MoE models under ZeRO-3, `_initialize_missing_keys` coalesced every uninitialized parameter into a single `GatheredParameters` all-gather. For models with packed expert weights this can re-materialize hundreds of GB on rank 0 and OOM.

## Test plan
- [x] Existing `test_init_zero3_missing_params` still validates missing-key initialization under ZeRO-3
- [ ] Manual repro from #46822 on multi-GPU with DeepSpeed ZeRO-3

Fixes #46822

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

no code agent PRs on random issues like this please!
Use common floats_list method for feature extractor tests.
Author: ebezzam
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=46956)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46956)
<!-- ci-dashboard-badge:end -->

# What does this PR do?

Refactor feature extractor tests to use common `floats_list` method.

cc: @vasqu

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46956)
**Latest run:** [28363860375:1](https://github.com/huggingface/transformers/actions/runs/28363860375)
**Result:** `success` | **Jobs:** 13 | **Tests:** 46,724 | **Failures:** 0 | **Duration:** 16h 18m

<!-- ci-dashboard-recap:end -->

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

run-slow: audio_spectrogram_transformer, clap, clvp, dia, encodec, gemma3n, gemma4_unified, musicgen, musicgen_melody, parakeet, phi4_multimodal, seamless_m4t, speech_to_text, speecht5, univnet, vibevoice_acoustic_tokenizer

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46956). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Add unit tests for `_ignore_causal_mask_sdpa` in `test_masking_utils.py`
Author: MosadCreates
Pull request: yes
Labels: name: Code agent slop

Adds 6 unit tests for `_ignore_causal_mask_sdpa` in `masking_utils.py` 
to the existing `tests/utils/test_masking_utils.py` file.

The function had no direct unit tests. These tests cover the four 
conditions that determine whether the causal mask can safely be skipped:

- No padding + single query token → skip (True)
- No padding + query_length == kv_length → skip (True)
- Padding present → do not skip (False)
- query_length > 1 and kv_length != query_length → do not skip (False)
- Local attention window active and kv_length exceeds it → do not skip (False)
- Local attention window set but kv_length within it → skip (True)

All 6 tests pass locally. No new files added. One import added to 
existing import block in `test_masking_utils.py`.

I confirm this is not a pure code agent PR.

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

Understood. To clarify — I wrote these tests after reading the source and understanding the four skip conditions directly. Happy to discuss the approach if that's useful. No objection to the closure.
docs(conditional_detr): fix num_queries default in docstring (100 -> 300)
Author: Kropiunig
Pull request: yes

The `num_queries` docstring in `ConditionalDetrConfig` says it "defaults to 100", but the actual class attribute is `num_queries: int = 300`. The `100` is a leftover copy from vanilla DETR; Conditional DETR uses 300 object queries (matching the `microsoft/conditional-detr-resnet-50` checkpoint), and the `300` default has been stable across releases. This corrects the documented default to 300.

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

run-slow: conditional_detr

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

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46939). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
[`Layer Types`] Split keys across MLP and Attentions
Author: vasqu
Pull request: no
Labels: name: WIP

See #46220, we have at some point merged all layer types into one. But they should be different for MLPs and Attentions. We are now stuck in a BC cycle, so we likely need to be breaking at some point 

cc @zucchini-nlp @Cyrilvallez 

Comments:
Hi, I’m interested in helping with this. Before attempting a PR, could you clarify the expected split between MLP layer type keys and Attention layer type keys, and whether the fix should preserve backward compatibility or intentionally introduce a breaking change?

Hey @Mubeen16 appreciate the thought but this pretty internal logic so I'd rather have this to be done from someone from our team instead. 

The issue kind of points to `ALL_LAYER_TYPES` (in modeling utils) now being merged (previously it wasn't) so we should resplit them at some point again

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md) are likely to be ignored.

Yes, completely agree, they should be different!
[docs] EP plan validation
Author: stevhliu
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=46900)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46900)
<!-- ci-dashboard-badge:end -->

Add docs for #46818

- Add a sentence that EP plan is required and validated. Requesting `enable_expert_parallel=True` on a model with no EP plan (`base_model_ep_plan`) raises a clear `ValueError` instead of silently falling back.
- Add a note to use a `scale_fmt="ue8m0"` checkpoint, or switch to `grouped_mm/batched_mm`, which read float32 scales directly.

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46900)
**Latest run:** [28201431875:1](https://github.com/huggingface/transformers/actions/runs/28386657336)
**Result:** `success` | **Jobs:** 2 | **Tests:** 24 | **Failures:** 0 | **Duration:** 1m 51s

<!-- ci-dashboard-recap:end -->

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46900). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Remove default dtype in FusedRMSNormGated modules
Author: Cyrilvallez
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=46953)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46953)
<!-- ci-dashboard-badge:end -->

# What does this PR do?

Follow-up of https://github.com/huggingface/transformers/pull/46817. As mentionned, device and dtype should never be explicit in module instantiation.
cc @vasqu

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46953)
**Latest run:** [28350254198:1](https://github.com/huggingface/transformers/actions/runs/28350254198)
**Result:** `success` | **Jobs:** 2 | **Tests:** 13 | **Failures:** 0 | **Duration:** 1m 10s

<!-- ci-dashboard-recap:end -->

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

run-slow: olmo_hybrid, qwen3_5, qwen3_5_moe, qwen3_next

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46953). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Enable using different MoE implementations in GraniteMoE
Author: mbknust
Pull request: yes

### Changes

I've changed `models/granitemoe/modular_granitemoe.py`, so that it uses `MixtralExperts` and `MixtralTopKRouter` instead of `JetMoeParallelExperts` and `JetMoeTopKGating`. From what I've seen, almost all MoE models have implementations based on Mixtral. Since `MixtralExperts` uses the `@use_experts_implementation` decorator, this PR will enable switching out the MoE module implementation inside GraniteMoE as well. The change also affects the two derived architectures: `granitemoeshared` and `granitemoehybrid`.

Since Mixtral's parameters have different names, I've had to add some renamings to `src/transformers/conversion_mapping.py`.

With the new gating module, the original reason for `_can_compile_fullgraph = False` no longer applies, so I've set it to True, except for `granitemoehybrid`, where I've had to keep it False, due to some unrelated problem with that model. I've also set `_can_record_outputs`.

Since one of the MoE implementations that can be chosen is based on the `grouped_mm` operator, which requires that strides be 16-byte aligned, I've changed the model sizes in the test file to be multiples of 8 (see also #42697).

- [X] I confirm that this is not a pure code agent PR.
- [X] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request), Pull Request section?

### Who can review?
@IlyasMoutawwakil 

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

run-slow: granitemoe, granitemoehybrid, granitemoeshared

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=46526&sha=6f0df7

Closing this and hoping #46738 gets merged instead

thanks @mbknust !
the CI status should be a comment
Author: tarekziade
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=46976)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46976)
<!-- ci-dashboard-badge:end -->

# What does this PR do?

The CI recap should be a comment, not a description insertion

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46976)
**Latest run:** [28429691973:1](https://github.com/huggingface/transformers/actions/runs/28431273963)
**Result:** `success` | **Jobs:** 4 | **Tests:** 254 | **Failures:** 0 | **Duration:** 2m 22s

<!-- ci-dashboard-recap:end -->

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46976). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Allow PEFT quantized models with non-trainable quantizers
Author: JemmaUZH
Pull request: yes
Labels: name: Code agent slop

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=46964)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46964)
<!-- ci-dashboard-badge:end -->

Fixes #46736.

This updates `validate_quantization_for_training` so PEFT-wrapped quantized models are consistently exempted from the non-trainable quantized base model guards.

The existing logic already skipped PEFT models for the "purely quantized model" check, but the following "quantization method does not support training" branch still rejected them. That blocks LoRA adapter fine-tuning flows created with `get_peft_model(...)`, even though the quantized base model itself is not being trained.

The change keeps the existing error for non-PEFT quantized base models and adds tests for both paths.

Tests:
```
python -m pytest tests/trainer/test_trainer.py -k "non_peft_quantized_model_with_non_trainable_quantizer_raises or peft_quantized_model_with_non_trainable_quantizer_is_allowed"
```

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46964)
**Latest run:** [28390211132:2](https://github.com/huggingface/transformers/actions/runs/28390211132)
**Result:** `failure` | **Jobs:** 14 | **Tests:** 67,159 | **Failures:** 67 | **Duration:** 12h 25m

<!-- ci-dashboard-recap:end -->

Comments:
The Transformers team is able to run a code agent and does not need you to do it for us. If you're not going to add anything beyond the code agent output, you should not be contributing to open source.
Fix AttributeError when window_size is set in TimesFm2_5ModelForPrediction
Author: aoright
Pull request: yes
Labels: name: Code agent slop

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=46973)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46973)
<!-- ci-dashboard-badge:end -->

This PR resolves issue #46821 where setting `window_size` in `TimesFm2_5ModelForPrediction.forward` raises an `AttributeError` due to calling `self._timesfm_moving_average` (which was renamed to `_timesfm2_5_moving_average` during modular conversion/refactoring).

### Changes
1. Updated the call site in `src/transformers/models/timesfm2_5/modular_timesfm2_5.py` to use `self._timesfm2_5_moving_average` instead of `self._timesfm_moving_average`.
2. Regenerated `src/transformers/models/timesfm2_5/modeling_timesfm2_5.py` by running `utils/checkers.py modular_conversion --fix`.
3. Added a new unit test `test_window_size` in `tests/models/timesfm2_5/test_modeling_timesfm2_5.py` to prevent regression.

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46973)
**Latest run:** [28419394746](https://github.com/huggingface/transformers/actions/runs/28419394746)
**Result:** `success` | Grafana metrics are not available yet.

<!-- ci-dashboard-recap:end -->

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

run-slow: timesfm2_5

There's an existing PR at #46834. We're currently swamped by code agent spam like this, and dealing with these PRs hurts open source because it wastes maintainer time. PLEASE do the homework and check for other/related PRs, reproduce the bug, etc. etc. rather than just trusting your code agent and dumping its output onto us to review
Better and more extensive tests for RoPE
Author: zucchini-nlp
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=46912)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46912)
<!-- ci-dashboard-badge:end -->

# What does this PR do?

As per title, no more RoPE-related issues! This should cover most cases with single rope or different rope per layer types.

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46912). 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, bamba, deepseek_v4, diffusion_gemma, efficientloftr, eurobert, evolla, gemma3, gemma3n, gemma4, gemma4_unified, glm_moe_dsa, jina_embeddings_v3, laguna, mellum, minicpmv4_6

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46912)
**Latest run:** [28450528757:1](https://github.com/huggingface/transformers/actions/runs/28450528757)
**Result:** `failure` | **Jobs:** 14 | **Tests:** 57,849 | **Failures:** 6 | **Duration:** 18h 44m

<!-- ci-dashboard-recap:end -->