noamaanMulla-03/transformers-issues huggingface dataset:
CI: add serge verify (GPU) caller workflow
Author: tarekziade
Pull request: yes

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

## What
A `workflow_dispatch` caller that delegates to the reusable `serge-verify-slow` workflow in [huggingface/transformers-ci](https://github.com/huggingface/transformers-ci) ([PR #30 there](https://github.com/huggingface/transformers-ci/pull/30)).

It runs a serge failure group's **targeted `@slow` test node-ids on a GPU twice** — the pre-patch **baseline** (must be red) and serge's **patched** candidate (want green), optionally the full `tests/models/<model>` slow suite on both — and emits a `serge-verify-result-*` artifact with a verdict (`fixed | not_fixed | already_passing | broke_others | error`).

## Why
serge opens fix PRs **without running the failing tests** — they're `@slow`/`[multi-gpu]` and don't run in normal PR CI, so a no-op patch (e.g. #47150) looks plausible and merges clean. This lets serge **verify red → green before opening a PR**.

## Notes
- Reuses the exact run-slow infrastructure via the transformers-ci reusable workflow — same prebaked image, same warm `/mnt/cache` model cache, same GPU runner groups. Nothing new to provision.
- **Gate:** GitHub only lets identities with **write access** run `workflow_dispatch`, which is itself the maintainer gate — same reasoning as `nightly-integration-failure-triage-caller.yml`. Runs LLM-generated patch code on GPU exactly like `run-slow`; carries only the read-only HF token via `secrets: inherit`.
- No effect until dispatched; adds no scheduled load.

Part of the serge GPU verify loop (design + verdict tool live in transformers-ci). Next: serge dispatches this and polls the artifact (≤2 feedback rounds, open-or-close).

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_47381). 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=47381)
**Latest run:** [29566703702:1](https://github.com/huggingface/transformers/actions/runs/29569029540)
**Result:** `success` | **Jobs:** 2 | **Tests:** 24 | **Failures:** 0 | **Duration:** 1m 48s

<!-- ci-dashboard-recap:end -->
BLT: vectorize patch length processing
Author: sj0618
Pull request: yes

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

## Summary

`process_patch_lengths` iterated over GPU tensors in Python and called `.item()` for every positive patch length. This can synchronize the host with the device repeatedly during BLT inference.

The implementation now performs chunk counting, segment construction, padding, and compaction with tensor operations. The generated `modeling_blt.py` copy is updated from `modular_blt.py`, and a regression test covers uneven patch lengths and zero padding.

## Related issue

Addresses #42422.

## Verification

- `ruff check` on all changed Python files
- `ruff format --check` after formatting
- direct CPU correctness check for both modular and generated implementations
- `py_compile` on implementation and test files
- GPU benchmark unavailable on this machine

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

run-slow: blt

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

<!-- ci-dashboard-recap:end -->
Add chat input sanitization
Author: Rocketknight1
Pull request: yes

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

This PR adds special token sanitization for chat inputs. I debated trying to break up the special tokens by retokenizing them with normal tokens, or escaping them, but I think the simplest solution is just to remove them entirely, similar to `tokenizer.decode(skip_special_tokens=True)`. It should be quite uncommon for chat inputs to contain model special tokens, and when it does it's probably malicious, so I think it's fine if input is slightly distorted in those cases.

I also got a code agent to add some tests to make sure we catch various sneaky ways to smuggle in special tokens despite this!

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_47386). 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=47386)
**Latest run:** [29597770235:1](https://github.com/huggingface/transformers/actions/runs/29597770235)
**Result:** `success` | **Jobs:** 15 | **Tests:** 172,366 | **Failures:** 0 | **Duration:** 15h 28m

<!-- ci-dashboard-recap:end -->
Finetuning Whisper with adapter with MAML
Author: LYPinASR
Pull request: no
Labels: name: Feature request

name: Audio

### Feature request

MAML is a widely used meta-learning method for reinitializing model parameters, which can effectively cope with low-resource situations.
As Whisper is a pre-trained model, its parameters cannot be reinitialized, but the bottleneck structure adapter can be applied to the encoder and decoder layers of the model, and then the adapter can be trained using MAML.
Request code for fine-tuning Whisper with adapter using MAML such as meta-training with 6 languages and final fine-tuning with 4 other languages.

### Motivation

low-resource ASR.

### Your contribution

Anything you need and I can.

Comments:
cc @sanchit-gandhi @ylacombe 

Hey @LYPinASR, not sure to understand what exactly is the requested feature? Do you have any code or paper pointers ?
Thanks!

Hi @LYPinASR, sorry for the very slow follow-up here, we're catching up on the backlog.

MAML is a meta-learning training procedure (an inner/outer optimization loop) rather than a model feature, so a native implementation is out of scope for transformers core; that logic belongs in your own training script. For the adapter side, bottleneck adapters on the Whisper encoder/decoder are best added via PEFT (https://github.com/huggingface/peft), which plugs directly into a `WhisperForConditionalGeneration`; you can then wrap the PEFT-adapted forward passes in your own MAML loop.
Plus @ylacombe's earlier request for a paper/code pointer went unanswered
[serge] integration failure triage - 2026-07-16
Author: github-actions[bot]
Pull request: no

<!-- serge-triage-run:integration-failure-triage:2026-07-16 -->

Automated **integration-failure triage** for the daily CI window `2026-07-08 → 2026-07-16`.

This issue was generated by AI-assisted automation. The grouping, summaries, and recommended follow-up can be incomplete or misleading; verify the failures before acting.

Serge dispatched one task per failure group below — each opens or updates its own PR on a `serge/fix/itf-<fingerprint>` branch. This table is refreshed in place as Serge runs: a group links its `#<pr>` when opened, shows `🚫 no fix` when Serge found no safe change, `⚠️ task failed` on error, or `(pending)` while still running (a late PR links on the next nightly run).

## Dispatched failure groups

| Model | Error | Occurrences | PR |
| --- | --- | --- | --- |
| `whisper` | other — other (20), shape/size mismatch (2) | 22 | ⚠️ task failed |
| `whisper` | output_mismatch — list output differs (10), other (6), tensor values differ (4) | 20 | #47150 |
| `musicgen_melody` | output_mismatch — tensor values differ (16) | 16 | 🚫 no fix |
| `gemma` | output_mismatch — list output differs (14) | 14 | 🚫 no fix |
| `edgetam` | import_or_config — other (12) | 12 | #47122 |
| `glm46v` | other — other (12) | 12 | #47281 |
| `hunyuan_vl` | output_mismatch — list output differs (8), other (4) | 12 | 🚫 no fix |
| `minimax_m3_vl` | load_error — other (12) | 12 | #47280 |
| `diffusion_gemma` | output_mismatch — tensor values differ (6), list output differs (4) | 10 | 🚫 no fix |
| `gemma3` | output_mismatch — list output differs (8), other (2) | 10 | #47310 |
| `gemma3n` | output_mismatch — list output differs (10) | 10 | 🚫 no fix |
| `glm_ocr` | output_mismatch — list output differs (10) | 10 | ⚠️ task failed |
| `deepseek_v32` | load_error — other (8) | 8 | #47266 |
| `falcon_mamba` | output_mismatch — other (6), list output differs (2) | 8 | #47124 |
| `grounding_dino` | output_mismatch — tensor values differ (6), other (2) | 8 | 🚫 no fix |
| `higgs_audio_v2` | output_mismatch — tensor values differ (8) | 8 | 🚫 no fix |
| `mamba2` | OOM — other (8) | 8 | #47380 |
| `mllama` | output_mismatch — other (8) | 8 | 🚫 no fix |
| `mpt` | other — other (8) | 8 | ⚠️ task failed |
| `peft_integration` | other — other (8) | 8 | 🚫 no fix |

_Generated 2026-07-17T02:41:24+00:00._

Comments:
Superseded by #47390 — closing this stale nightly integration-failure triage issue. Open PRs stay linked from the current issue.
Can we change mistral attention bias=False to bias=config.attention_bias ？
Author: Minami-su
Pull request: no
Labels: name: Feature request

just like llama attention ![image](https://github.com/huggingface/transformers/assets/76865636/f483aa4c-6c8f-40fd-b942-784cf74774cf)


Comments:
@Minami-su Thanks for this feature request! Could you provide some more context on why you'd like to have this feature added? 

In principle, it can be done by adding the `config.attention_bias` param which defaults to False. Care will need to be taken to make sure this is properly propagated and backwards compatible with any models which copy mistral's attention. 

You'll also need to make sure that if `config.attention_bias=True` then the flash attention and SDPA attentions remain equivalent to the eager implementation. 

![image](https://github.com/huggingface/transformers/assets/76865636/7569f37c-bb16-464a-85fd-4fb6047f624b)
The default setting for mistral is bias=False,so setting config.attention_bias=True is useless
@amyeroberts 

@Minami-su If it's useless then there's no point in adding this config parameter 

> @Minami-su If it's useless then there's no point in adding this config parameter

I have a model https://huggingface.co/Minami-su/Qwen1.5-7B-Chat_mistral
Because qwen attention has bias weight, but the model architecture is mistral,so....

> so setting config.attention_bias=True is useless

If this is useless then there's 0 value in being able to set this. If it's not useless, and you do want to add a config parameter to control the addition of bias, such as you've done in your custom model, then it's necessary to make sure the different attention layers remain equivalent. 

Hey @Minami-su, sorry for the very late follow-up, we're catching up on the backlog.

The case you described (a Qwen1.5 checkpoint, which carries q/k/v attention bias, running under a Mistral-style architecture) is already covered natively by the Qwen2 architecture in transformers: it is structurally Mistral but with `bias=True` on q/k/v and `bias=False` on o_proj, exactly what Qwen1.5 needs, see https://github.com/huggingface/transformers/blob/150eb7c9ed4091294c829fa0e9466b090cb0f87f/src/transformers/models/qwen2/modeling_qwen2.py#L200-L203
So you can load Qwen1.5 directly with `Qwen2ForCausalLM` instead of re-mapping it onto Mistral. Adding a generic `attention_bias` flag to Mistral itself would need careful propagation and backward-compat handling across the ~13 models that derive from Mistral's attention, and as you noted a genuine Mistral checkpoint has no bias weights to load, so we'd rather not add a permanent config field with essentially no upstream demand. Closing as won't-implement, but happy to reconsider if a broader need with more +1s shows up.
XVector Finetuning process - Whisper XVector
Author: rafael-ariascalles
Pull request: no
Labels: name: New model

### Model description

The idea is to apply XVector to Whisper and, In the process, generate documentation to Finetune or Adapt XVector (Maybe something similar to SetFit for Audio)  @vaibva

### Open source status

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

### Provide useful links for the implementation

_No response_

Comments:
Hey @rafael-ariascalles, sorry for the very late reply, we're catching up on the backlog.

transformers already ships XVector speaker-verification heads on the audio encoders designed for that task: `Wav2Vec2ForXVector`, `UniSpeechSatForXVector`, `Data2VecAudioForXVector` and `Wav2Vec2BertForXVector` see https://github.com/huggingface/transformers/blob/150eb7c9ed4091294c829fa0e9466b090cb0f87f/src/transformers/models/wav2vec2/modeling_wav2vec2.py#L2004
so speaker embeddings/finetuning are covered there today. Whisper is an ASR encoder-decoder and a native `WhisperForXVector` isn't on the roadmap. New architectures follow the Model-on-the-Hub-first path, so the fastest route is a custom model with `trust_remote_code=True`, and if it gains traction a `modular_whisper_xvector.py` PR would be very welcome.

Closing as won't implement for now, but happy to revisit if you can share a reference implementation or there's broader demand.
Saving logs to file
Author: techkang
Pull request: no
Labels: name: Feature request

### Feature request

Add a `FileHandler` to root logger.

### Motivation

Transformers is only using StreamHandler for logging, which makes debug analysis hard across different experiments. Many other frameworks support both logging to terminal and to file.
For example: fairseq: https://github.com/facebookresearch/fairseq/blob/ecbf110e1eb43861214b05fa001eff584954f65a/fairseq_cli/train.py#L63-L65
detectron2: 
https://github.com/facebookresearch/detectron2/blob/8d85329aed8506ea3672e3e208971345973ea761/detectron2/utils/logger.py#L108

### Your contribution

I can propose a PR.

Comments:
If you feel like offering a PR, that would be great! It can likely just be a doc PR showing how to add a new logging handler serializing the logs to a file.

Hey @techkang, sorry for the very slow reply here, we're catching up on the feature-request backlog.

Good news: this already works today without any native change. `transformers.utils.logging` exposes a public `add_handler()` that accepts any `logging.Handler`, so you can serialize logs to a file with:

```python
import logging
from transformers.utils import logging as hf_logging
hf_logging.add_handler(logging.FileHandler("transformers.log"))
```

Since the capability is already there, we'd rather not add a native FileHandler/config field for it
fix(trainer): fix resume_from_checkpoint logic bug (issue #47375)
Author: varneeth01
Pull request: yes

What does this PR do?
Fixes #47375

**This PR fixes two correctness issues in the examples/pytorch/*/run_*_no_trainer.py scripts.**

1. Fix resume_from_checkpoint logic

The previous condition:

_**if args.resume_from_checkpoint is not None or args.resume_from_checkpoint != "":**_

- prevented the automatic checkpoint discovery path from being reached when an empty string was provided.
- This PR changes the condition to require both checks so an empty string correctly triggers automatic checkpoint discovery.

2. Fix evaluation loss normalization

- Several no_trainer examples normalized evaluation loss using the configured batch size instead of the actual batch size from the input tensors.

This produced incorrect metrics for the final partial batch.
This PR updates those examples to use the actual batch size when computing evaluation loss and perplexity.

Comments:
Thank you for your contribution 🤗!

## CI Security Gate — automatic approval blocked

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

**Possible reasons:**
- The PR touches 50 or more files — only PRs with fewer than 50 changed files are automatically approved
- A changed file is outside the allowed directories (`src/`, `tests/`, `docs/`, `utils/`), has a disallowed extension (only `.py`, `.txt`, `.md` permitted outside `tests/` and `docs/`), or is not `.md`/`.yml` inside `docs/`
- A new high-severity security issue was detected in the changed Python files (Bandit check)

See the [workflow run](https://github.com/huggingface/transformers/actions/runs/29631245689) for the exact violations.

A maintainer can review and manually approve CI if a finding is a false positive.
[WIP] Support one-to-many conversions
Author: kylesayrs
Pull request: yes

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

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=47387)
**Latest run:** [29631286467:2](https://github.com/huggingface/transformers/actions/runs/29631286467)
**Result:** `failure` | **Jobs:** 2 | **Tests:** 21 | **Failures:** 1 | **Duration:** 2m 0s

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

<!-- ci-dashboard-recap:end -->
[Inkling] Fix float64 MPS crash in InklingProcessor dMel bin extraction
Author: alwaysprince05
Pull request: yes

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

## What does this PR do?

`InklingProcessor._extract_dmel_bins` (src/transformers/models/inkling/processing_inkling.py) hardcodes `torch.float64` when upcasting `input_features` and creating `bin_centers`. The MPS backend on Apple Silicon does not support float64, so any Inkling audio processing on an MPS device raises:

```
TypeError: Cannot convert a MPS Tensor to float64 dtype as the MPS framework does not support float64
```

## Fix

Fall back to `float32` on MPS and keep `float64` elsewhere, matching the existing precedent in `whisper/generation_whisper.py:801`:

```python
compute_dtype = torch.float32 if input_features.device.type == "mps" else torch.float64
```

The dMel binning uses 16 bins over the range `[-7.0, 2.0]` — float32 precision is more than sufficient, and the int32 bin indices are identical between the two dtypes (verified on CPU).

## Before submitting

- [x] Did you read the contributor guideline?
- [x] Did you run `make style`?
- [x] Did you run `make typing`?
- [x] Did you run `make fix-repo`?
- [x] Did you run `make check-repo`?
- [x] Did you test your changes locally with `RUN_SLOW=1 pytest tests/models/inkling/test_processing_inkling.py`?

## AI assistance disclosure

The bug diagnosis was AI-assisted; the fix was written, verified, and submitted by me.

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

run-slow: inkling

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

<!-- ci-dashboard-recap:end -->
fix: upgrade http:// to https:// in README
Author: hanu-14
Pull request: yes

fix: upgrade http:// to https:// in README.

Comments:
Thank you for your contribution 🤗!

## CI Security Gate — automatic approval blocked

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

**Possible reasons:**
- The PR touches 50 or more files — only PRs with fewer than 50 changed files are automatically approved
- A changed file is outside the allowed directories (`src/`, `tests/`, `docs/`, `utils/`), has a disallowed extension (only `.py`, `.txt`, `.md` permitted outside `tests/` and `docs/`), or is not `.md`/`.yml` inside `docs/`
- A new high-severity security issue was detected in the changed Python files (Bandit check)

See the [workflow run](https://github.com/huggingface/transformers/actions/runs/29635973465) for the exact violations.

A maintainer can review and manually approve CI if a finding is a false positive.
MPS: DynamicCache produces NaN logits mid-decode in generate() (transformers >=5.2, regression from 5.0)
Author: scp7
Pull request: no

## Summary

On Apple Silicon (MPS), transformers **>= 5.2.0** produces NaN logits during autoregressive `generate()` with the default cache (DynamicCache), surfacing as:

```
RuntimeError: probability tensor contains either `inf`, `nan` or element < 0
  File ".../transformers/generation/utils.py", line 2808, in _sample
    next_tokens = torch.multinomial(probs, num_samples=1).squeeze(1)
```

Setting **`cache_implementation="static"` avoids it entirely**. transformers **5.0.0 is stable** on the identical workload and identical torch; 5.2.0, 5.8.1 and 5.14.1 all reproduce — so the regression entered with the 5.2 cache refactor and is still present.

## Key diagnostic facts

Instrumenting `torch.multinomial` in the live failure (rather than a synthetic repro) established:

- The failing `generate` is **single-sequence** — `probs.shape == (1, vocab)`, no padding, so this is **not** the fully-masked-row / SDPA-mask issue (pytorch#156707).
- The **entire logits row** is NaN (`nan_count == vocab_size`), and it happens **mid-decode** — after ~900 successful sampling steps in the run, not at the first token.
- It is **intermittent**: single-shot `generate()` probes (even multi-turn, batched, LoRA, gradient-checkpointed, exact GenerationConfig) never reproduce it; it needs the sustained generation of a real training loop.
- **`cache_implementation="static"` completes cleanly** where DynamicCache fails, on the same version/seed/workload — isolating the fault to the dynamic cache path on MPS.

## Environment

- Apple M4 Max, macOS (Metal), 48 GB
- torch 2.9.1 (constant across all experiments)
- transformers 5.2.0 / 5.8.1 / 5.14.1 reproduce; 5.0.0 does not
- Model: Qwen/Qwen3-0.6B, bfloat16, SDPA, PEFT/LoRA adapter
- Workload: TRL 1.8.0 GRPOTrainer tool-calling rollouts (multi-turn generation)

## Reproduction

Full repro is a TRL GRPO tool-rollout run (open source: nolabs-ai/hedgehog). A minimal standalone repro has been elusive precisely because the fault needs sustained/pipelined decode pressure — single `generate()` calls always succeed. Happy to run diagnostics on the affected hardware.

## Workaround

`cache_implementation="static"` in the generation config. (In isolation this is ~as fast as dynamic; in a loop with varying shapes it recompiles per shape and is ~3x slower without torch.compile — but it is correct.)

## Ask

Either the MPS DynamicCache path needs the same numerical guard the static path has, or triage toward the underlying torch MPS behavior if that's where the corruption originates.


Comments: