noamaanMulla-03/transformers-issues huggingface dataset:
Add regression test for register() with a string config_class key
Author: pablopupo
Pull request: yes
Labels: name: Code agent slop

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

#46876 added an unconditional key.__module__ read in _LazyAutoMapping.register, which broke downstream code that registers with a plain string instead of a config class (strings have no __module__). #47148 fixed this with a getattr fallback and widened the type hint to type[PreTrainedConfig] | str, but shipped without a test. This adds one, exercising _LazyAutoMapping.register directly with a string key and checking it lands in _extra_content instead of raising.

- [✅] (First-time contributors only): I confirm that this PR description and code is not written by an LLM or code agent

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

run-slow: auto

<!-- 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=47263)
**Latest run:** [29167274494](https://github.com/huggingface/transformers/actions/runs/29167274494)
**Result:** `success` | Grafana metrics are not available yet.

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

That patch is definitely written by a code agent

> That patch is definitely written by a code agent

It wasn't, and I'd be interested to see why you reported it as such without any evidence?

that might work on your professor but it's not going to work on an AI engineer at Hugging Face lol. blocked, get outta here
Fix check for interactive stdout in _style function
Author: smart8986
Pull request: yes

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

I encountered an error when I set 'sys.stdout' to 'None' to turn off logging.

Comments:
<!-- 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=47283)
**Latest run:** [29222140039](https://github.com/huggingface/transformers/actions/runs/29222140039)
**Result:** `success` | Grafana metrics are not available yet.

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

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

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

# What does this PR do?

Draft pull request for experimenting purposes, feel free to ignore.

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

<!-- 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=47034)
**Latest run:** [28626992390:1](https://github.com/huggingface/transformers/actions/runs/28626992390)
**Result:** `failure` | **Jobs:** 15 | **Tests:** 58,101 | **Failures:** 0 | **Duration:** 18h 22m

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

Work is done, closing the PR.
Add serialization to hf_argparser.py
Author: ezhang7423
Pull request: yes
Labels: name: Feature request

# What does this PR do?

This PR introduces three key enhancements to the HfArgumentParser class within the Hugging Face Transformers library: the internal method _to, and the public methods to_json and to_yaml. These additions allow for seamless serialization of parsed command-line arguments (or any dataclass instances) into JSON and YAML files, facilitating better interoperability and configuration management for users.

The _to method serves as a generic serializer that underpins both to_json and to_yaml, abstracting the serialization process and ensuring that any dataclass instance can be easily saved in these formats. The to_json method leverages this to serialize dataclass instances to a JSON file, while to_yaml does the same for YAML files. Both methods are designed to work with tuples of dataclass instances, allowing for batch serialization of multiple configurations at once.

This functionality enhances the library's usability by providing users with a straightforward way to save and share model configurations, training parameters, or any other dataclass-based settings. This is particularly useful for reproducing experiments, sharing configurations across teams, or for logging purposes.

Documentation has been updated accordingly to include these new methods, along with examples and guidelines on how to use them effectively. Tests have been added to verify the correctness of the serialization process and to ensure that it works as expected for a variety of dataclass structures.

## 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).
- [ ] 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.

Tagging @ArthurZucker @konstantinjdobler  @sgugger 




Comments:
[WIP] [performance doc] faster/leaner optimizers
Author: stas00
Pull request: yes
Labels: name: WIP

documenting faster / leaner optimizers

TODO:

- add `--optim adamw_bnb_8bit` for HF Trainer.


Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_14708). All of your documentation changes will be reflected on that endpoint.
Fix token not propagated to get_config_dict in PreTrainedConfig.from_pretrained
Author: rodrigoheniquesouza
Pull request: yes
Labels: name: Code agent slop

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

## Summary

When calling `PreTrainedConfig.from_pretrained("model", token="xxx")`, the `token` parameter is captured as a named argument but never forwarded to `get_config_dict` → `_get_config_dict`. The token is silently ignored, causing downloads of gated/config-restricted models to fail even with a valid token.

## Root cause

`configuration_utils.py:675-678`: `cache_dir`, `force_download`, `local_files_only`, and `revision` are all explicitly added to kwargs, but `token` is not. `_get_config_dict` (line 743) pops `token` from kwargs and gets `None`.

## Fix

```python
kwargs["cache_dir"] = cache_dir
kwargs["force_download"] = force_download
kwargs["local_files_only"] = local_files_only
kwargs["revision"] = revision
+ if token is not None:
+     kwargs["token"] = token
```

## Note

The `_set_token_in_kwargs` mechanism in `AutoConfig` (auto_factory.py) works around this for the Auto class path, but direct `from_pretrained` calls were missed.

## AI Disclosure

This PR was prepared with assistance from an AI coding agent, under the supervision of a human contributor who reviewed all changes.

## Before submitting
- [ ] This PR fixes a typo or improves the docs.
- [ ] Did you read the contributor guideline?
- [ ] Was this discussed/approved via a Github issue?
- [ ] Did you write any new necessary tests?

## Who can review?

@CyrilValleys @ArthurZucker

Comments:
<!-- 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=47288)
**Latest run:** [29222412860:2](https://github.com/huggingface/transformers/actions/runs/29222412860)
**Result:** `failure` | **Jobs:** 2 | **Tests:** 24 | **Failures:** 0 | **Duration:** 2m 12s

<!-- ci-dashboard-recap:end -->
Fix NaN loss in metrics when eval dataset produces no losses
Author: rodrigoheniquesouza
Pull request: yes
Labels: name: Code agent slop

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

## Summary

When `all_losses` is an empty numpy array (no loss outputs in eval batch), `all_losses.mean()` returns `NaN`, which propagates into reported metrics.

## Root cause

`trainer.py:2834-2837`: The `elif isinstance(all_losses, np.ndarray)` branch does not guard against empty arrays. The `list` branch has `and all_losses` truthiness check, but the numpy branch is missing the equivalent guard.

## Fix

```
- elif isinstance(all_losses, np.ndarray):
+ elif isinstance(all_losses, np.ndarray) and all_losses.size > 0:
```

## AI Disclosure

This PR was prepared with assistance from an AI coding agent, under the supervision of a human contributor who reviewed all changes.

## Before submitting
- [ ] This PR fixes a typo or improves the docs.
- [ ] Did you read the contributor guideline?
- [ ] Was this discussed/approved via a Github issue?
- [ ] Did you write any new necessary tests?

## Who can review?

@SunMarc

Comments:
<!-- 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=47287)
**Latest run:** [29222407905:2](https://github.com/huggingface/transformers/actions/runs/29222407905)
**Result:** `success` | **Jobs:** 2 | **Tests:** 24 | **Failures:** 0 | **Duration:** 2m 8s

<!-- ci-dashboard-recap:end -->
Fix pad_token_id=0 silently replaced by eos_token_id in beam search
Author: rodrigoheniquesouza
Pull request: yes
Labels: name: Code agent slop

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

## Summary

When `pad_token_id` is 0 (the most common value, e.g., BERT, GPT-2), the expression `pad_token_id or eos_token_id[0]` evaluates to `eos_token_id[0]` because `bool(0)` is `False` in Python. This causes beam search to use the wrong fill value for padding, corrupting output sequences.

## Root cause

`generation/utils.py:3308`: `output_fill_value = pad_token_id or eos_token_id[0] if eos_token_id is not None else -1`

Python's `or` operator tests truthiness. `pad_token_id=0` is falsy, so it falls through to `eos_token_id[0]`.

## Fix

```
- output_fill_value = pad_token_id or eos_token_id[0] if eos_token_id is not None else -1
+ output_fill_value = pad_token_id if pad_token_id is not None else (eos_token_id[0] if eos_token_id is not None else -1)
```

Uses explicit `is not None` instead of truthiness.

## Impact

Any model with `pad_token_id=0` using beam search will silently produce wrong outputs. One-line change with no side effects.

## AI Disclosure

This PR was prepared with assistance from an AI coding agent, under the supervision of a human contributor who reviewed all changes.

## Before submitting
- [ ] This PR fixes a typo or improves the docs.
- [ ] Did you read the contributor guideline?
- [ ] Was this discussed/approved via a Github issue?
- [ ] Did you write any new necessary tests?

## Who can review?

@gante

Comments:
<!-- 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=47286)
**Latest run:** [29222402828](https://github.com/huggingface/transformers/actions/runs/29222402828)
**Result:** `failure` | Grafana metrics are not available yet.

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

<!-- ci-dashboard-recap:end -->
Fix ZeroDivisionError in polynomial decay when warmup equals training steps
Author: rodrigoheniquesouza
Pull request: yes
Labels: name: Code agent slop

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

## Summary

When `num_warmup_steps == num_training_steps` in `get_polynomial_decay_schedule_with_warmup`, `decay_steps` becomes 0, causing a `ZeroDivisionError` at `optimization.py:236`.

## Root cause

`decay_steps = num_training_steps - num_warmup_steps` — when warmup fills the entire schedule, `decay_steps = 0`.

## Fix

`decay_steps = max(1, num_training_steps - num_warmup_steps)`

This gracefully skips the decay phase when there are no decay steps.

## How to reproduce

```python
from transformers import get_polynomial_decay_schedule_with_warmup
from torch.optim import SGD
from torch.nn import Linear

model = Linear(2, 1)
optimizer = SGD(model.parameters(), lr=0.01)
scheduler = get_polynomial_decay_schedule_with_warmup(
    optimizer, num_warmup_steps=100, num_training_steps=100, power=2.0, lr_end=1e-7,
)
scheduler.step()  # ZeroDivisionError
```

## AI Disclosure

This PR was prepared with assistance from an AI coding agent, under the supervision of a human contributor who reviewed all changes.

First-time contributor checkbox: leaving unchecked per policy.

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that is the case).
- [ ] Did you read the [contributor guideline](https://huggingface.co/docs/transformers/contributing)?
- [ ] Was this discussed/approved via a Github issue?
- [ ] Did you write any new necessary tests?

## Who can review?

@muellerzr

Comments:
<!-- 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=47285)
**Latest run:** [29222397714](https://github.com/huggingface/transformers/actions/runs/29222397714)
**Result:** `failure` | Grafana metrics are not available yet.

<!-- ci-dashboard-recap:end -->
Fix Double Application of Softmax for Router Logits in MoE models
Author: ionut-anghelina
Pull request: yes


Comments:
@Rocketknight1 I'm not sure about the current state here so just left a comment here since it seemed the most recent state of things. Lmk if not or where I should properly look at

Let's also add the fixes and closes statements for the issue and other PR please

Ok #45131 was merged instead, we can still use this PR for tests tho @Rocketknight1 @ionut-anghelina 

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

run-slow: mixtral, qwen2_moe

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

This diff only adds tests, `test_modeling_mixtral.py` and `test_modeling_qwen2_moe.py`, no source change in either model's router code.

Checked both `MixtralTopKRouter.forward` and `Qwen2MoeTopKRouter.forward` against current `main`: both compute `router_logits = F.linear(hidden_states, self.weight)` and return that raw value as the first element (the one captured by `OutputRecorder(..., index=0)` into `outputs.router_logits`). `router_probs = softmax(router_logits, ...)` is a separate local variable used only to compute top-k routing weights, it's never what gets returned as `router_logits`. So on current `main`, `router_logits` already looks like raw logits, not softmax output, which is what the new regression tests assert.

Where's the actual double-softmax happening? If it's in `load_balancing_loss_func` (e.g. if `router_logits` ever gets passed in already-softmaxed from some other call site) rather than in the router forward itself, that source fix seems to be missing from this diff, only the router-output-level regression test is here. Want to make sure I'm not missing the actual repro before assuming this needs a source change added.


#45131 fixed it, and then this PR kind of got abandoned because it aimed to do the same :sweat_smile: 

That explains it, #45131 (merged 2026-04-13) is exactly what I was seeing on current `main`: both routers already return raw logits, not probabilities. Confirms the analysis rather than contradicts it, the fix landed, this PR's tests just never got reconciled with that. Makes sense to close this one as superseded.
[docs] MPS graph cache
Author: stevhliu
Pull request: yes

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

Adds docs for opting in to clear the graph and device cache on MPS (see #45818)

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

<!-- 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=47304)
**Latest run:** [29273683438:1](https://github.com/huggingface/transformers/actions/runs/29273683438)
**Result:** `success` | **Jobs:** 2 | **Tests:** 24 | **Failures:** 0 | **Duration:** 1m 56s

<!-- ci-dashboard-recap:end -->
Kernel native causal_conv1d functions
Author: Cyrilvallez
Pull request: yes

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

# What does this PR do?

As per the title. This makes `causal_conv1d_fn` and `causal_conv1d_update` kernels native! Needs to be extended to all models using them, but just for qwen to unblock me for now

cc @vasqu

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

It's getting complicated, we may revisit later but the interaction between og, kernels, and torch is akward

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

run-slow: qwen3_5, qwen3_5_moe, qwen3_next

<!-- 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=47294)
**Latest run:** [29275579323:1](https://github.com/huggingface/transformers/actions/runs/29275579323)
**Result:** `success` | **Jobs:** 2 | **Tests:** 24 | **Failures:** 0 | **Duration:** 2m 23s

<!-- ci-dashboard-recap:end -->
Point to Gemma 4 model in Gemma4ForCausalLM docstring example
Author: lefft
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47255)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47255)
<!-- ci-dashboard-badge:end -->


# What does this PR do?

Point to a Gemma 4 model in Gemma4ForCausalLM docstring instead of a Gemma 2 model. 

## Code Agent Policy

- [x] (First-time contributors only): I confirm that this PR description and code is not written by an LLM or code agent

## 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?
- [N/A] 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.
- [N/A] Did you make sure to update the documentation with your changes according to the [guidelines](https://github.com/huggingface/transformers/tree/main/docs)?
- [N/A] Did you write any new necessary [tests](https://huggingface.co/docs/transformers/testing)?


## Who can review?

@stevhliu for documentation, @ArthurZucker for text models (since this is the 4CausalLM class) 


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

run-slow: gemma4

<!-- 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=47255)
**Latest run:** [29126781067:2](https://github.com/huggingface/transformers/actions/runs/29127216059)
**Result:** `success` | **Jobs:** 2 | **Tests:** 24 | **Failures:** 0 | **Duration:** 2m 9s

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

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