noamaanMulla-03/transformers-issues huggingface dataset:
Fix CohereASR training-loss double-shift (same as Moonshine fix #46784)
Author: sharmax-vikas
Pull request: yes

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

# What does this PR do?

`CohereAsrForConditionalGeneration.forward()` has a training-loss double-shift bug — the same pattern fixed in Moonshine via #46784.

**The problem:**
1. Labels are shifted right via `shift_tokens_right()` to create `decoder_input_ids`
2. Then `self.loss_function()` is called, which maps to `ForCausalLMLoss`
3. `ForCausalLMLoss` shifts labels again internally (`labels[..., 1:]`)

This means the model trains against `labels[..., 1:]` instead of `labels`.

**The fix:** Replace `self.loss_function()` with plain `CrossEntropyLoss()`, matching Whisper, Bart, and the now-fixed Moonshine model.

Fixes #46894

## Code Agent Policy

- [x] I confirm that this is not a pure code agent PR.

## Before submitting

- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://huggingface.co/docs/transformers/contributing) and the [Pull Request](https://huggingface.co/docs/transformers/pr_checks) checks?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link to it if that's the case. — #46894
- [ ] Did you make sure to update the documentation with your changes according to the [guidelines](https://github.com/huggingface/transformers/tree/main/docs)?
- [ ] Did you write any new necessary [tests](https://huggingface.co/docs/transformers/testing)?



@eustlb @ebezzam @vasqu

Comments:
@vasqu 

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

run-slow: cohere_asr

<!-- 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=46895)
**Latest run:** [28676252763:2](https://github.com/huggingface/transformers/actions/runs/29069241652)
**Result:** `success` | **Jobs:** 5 | **Tests:** 332 | **Failures:** 0 | **Duration:** 4m 33s

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

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46895). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix flash-attn Docker build broken by setuptools 83 removing pkg_resources
Author: ydshieh
Pull request: yes

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

## Summary

- `torch 2.13.0` (released 2026-07-08 16:05 UTC) added an unconditional `setuptools>=77.0.3` requirement
- pip resolves this to `setuptools 83.0.0`, which **removed `pkg_resources`**
- The Ubuntu 22.04 system `wheel` package (`/usr/lib/python3/dist-packages/wheel/bdist_wheel.py`) still imports `pkg_resources`, causing flash-attn to fail during `--no-build-isolation` builds
- This explains why July 8 builds worked (torch 2.12.1, no unconditional setuptools constraint) and July 9+ builds fail

## Fix

Upgrade `wheel` to the latest pip-installed version right before building flash-attn. `wheel >= 0.43` (Feb 2024) migrated from `pkg_resources` to `importlib.metadata`, so it no longer depends on setuptools providing `pkg_resources`.

## Test plan

- [ ] Nightly `flash-attn-ci-image` Docker build succeeds after this merges

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

<!-- ci-dashboard-recap:end -->
Adding Omnilingual ASR models
Author: ebezzam
Pull request: yes
Labels: name: New model

name: Audio

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

# What does this PR do?

Adds Omnilingual ASR: https://github.com/facebookresearch/omnilingual-asr

CTC-variant
- [x] functional conversion to checkpoint that is (more) Transformers-compatible: https://huggingface.co/bezzam/omniasr-ctc-300m-v2
- [x] functional modeling (e.g. by trying with [example script](https://gist.github.com/ebezzam/26af2bd40fa207af322de39701179650#file-example_transformers_ctc_variant-py))
- [x] passing single + batch integration tests
```
CUDA_VISIBLE_DEVICES=1 RUN_SLOW=1 pytest tests/models/omniasr/test_modeling_omniasr.py::OmniASRForCTCIntegrationTest
```

LLM-variant
- [x] functional conversion to checkpoint that is (more) Transformers-compatible: https://huggingface.co/bezzam/omniasr-llm-300m-v2
- [x] functional modeling (e.g. by trying with [example script](https://gist.github.com/ebezzam/26af2bd40fa207af322de39701179650#file-example_transformers_llm_variant-py))
    - Probably need to define a new processor and tokenizer which can handle the language IDs? And then create a new checkpoint
- [x] passing single + batch integration tests
```
CUDA_VISIBLE_DEVICES=1 RUN_SLOW=1 pytest tests/models/omniasr/test_modeling_omniasr.py::OmniASRForConditionalGenerationIntegrationTest
```

When both CTC and LLM-variants working:
- [ ] (in progress) prune to essential code paths and config (iteratively update conversion script)
- [ ] (in progress) shift into [modular](https://huggingface.co/docs/transformers/en/modular_transformers) file, see what can be reused Wav2Vec2, SeamlessM4T, recent audio LMs
- [ ] custom tokenizer? atm using from `LasrTokenizer`
- [ ] full tests

Comments:
View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=43265&sha=96f6b6

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

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

run-slow: auto, omniasr

<!-- 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=43265)
**Latest run:** [28464792218:1](https://github.com/huggingface/transformers/actions/runs/29114137688)
**Result:** `failure` | **Jobs:** 14 | **Tests:** 116,676 | **Failures:** 1 | **Duration:** 20h 1m

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

<!-- ci-dashboard-recap:end -->
Torch compile backend defaults to "neuron"
Author: michaelbenayoun
Pull request: yes

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

# What does this PR do?

When `--torch-compile` is set and no backend is specified, defaults to "neuron" when a torch neuron is available.
Follows the same spirit as what's done for HPUs.

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

<!-- ci-dashboard-recap:end -->
[serge] integration failure triage - 2026-07-09
Author: github-actions[bot]
Pull request: no

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

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

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 | 🚫 no fix |
| `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 |
| `dac` | output_mismatch — tensor values differ (6), other (6) | 12 | 🚫 no fix |
| `edgetam` | import_or_config — other (12) | 12 | #47122 |
| `glm46v` | other — other (12) | 12 | 🚫 no fix |
| `minimax_m3_vl` | load_error — other (12) | 12 | 🚫 no fix |
| `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 | 🚫 no fix |
| `gemma3n` | output_mismatch — list output differs (10) | 10 | 🚫 no fix |
| `glm_ocr` | output_mismatch — list output differs (10) | 10 | 🚫 no fix |
| `deepseek_v32` | load_error — other (8) | 8 | 🚫 no fix |
| `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 |
| `mamba2` | OOM — other (8) | 8 | 🚫 no fix |
| `mllama` | output_mismatch — other (8) | 8 | 🚫 no fix |
| `mpt` | other — other (8) | 8 | 🚫 no fix |
| `peft_integration` | other — other (8) | 8 | 🚫 no fix |
| `recurrent_gemma` | output_mismatch — list output differs (8) | 8 | 🚫 no fix |

_Generated 2026-07-10T00:48:15+00:00._

Comments:
Superseded by #47256 — closing this stale nightly integration-failure triage issue. Open PRs stay linked from the current issue.
Switch AMD daily CI to mi300 runners
Author: Abdennacer-Badaoui
Pull request: yes

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

MI325 hardware is being retired; migrate the AMD daily CI to MI300.
Updates runner groups to `hfc-amd-mi300-{1,2}gpu` and labels to `amd-mi300-ci-{1,2}gpu`, and renames the mi325 caller workflows to mi300.

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=47259)
**Latest run:** [29147348738](https://github.com/huggingface/transformers/actions/runs/29147348738)
**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_47259). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix gradient inflation when combining label smoothing with gradient accumulation
Author: Incheonkirin
Pull request: yes

## What this fixes

`label_smoothing_factor > 0` with `gradient_accumulation_steps > 1` inflates gradients by ~`gradient_accumulation_steps` for any model whose forward accepts loss kwargs. Repro and write-up in #46731.

## Root cause

#34198 wired `num_items_in_batch` into `trainer.py` but not into `LabelSmoother` (`trainer_pt_utils.py`). When `model_accepts_loss_kwargs` is True, `training_step` skips the `1/gradient_accumulation_steps` normalization on the assumption the loss already divided by the effective batch — but `LabelSmoother` mean-reduces over the micro-batch instead. The same `num_items_in_batch` is already threaded into the adjacent `compute_loss_func` branch.

## Fix

- `LabelSmoother.__call__` takes `num_items_in_batch` and uses it as the denominator, falling back to the active-token count when it's `None` (so standalone calls are unchanged).
- `compute_loss` passes `num_items_in_batch` into both `label_smoother` calls.

## Test

`test_gradient_accumulation_grad_norm_with_label_smoothing`: the grad-norm ratio between a large-batch baseline and an equivalent accumulation run goes from ~9x at `gradient_accumulation_steps=8` to ~1.0. Existing `TrainerGradientAccumulationTest` / `TrainerLabelSmoothingTest` still pass.

## Backward compatibility

Changes loss/gradient magnitude by ~`gradient_accumulation_steps` for existing label-smoothing + accumulation runs (previously over-scaled). LRs tuned against the old magnitude may need re-checking.

## Scope

Single-device and default DDP token averaging become exact. Legacy DataParallel (`n_gpu > 1`) keeps the same `n_gpu` approximation the `compute_loss_func` path already has, so this doesn't add DP-specific behavior.

Closes #46731


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

Replacement PR is now #47261 from a proper fork. It contains the rebased change and current validation; no reopen is needed.
Respect min_tokens_to_keep in TopHLogitsWarper
Author: Incheonkirin
Pull request: yes

# What does this PR do?

`generate()` computes a `min_tokens_to_keep` value for sampling, using a larger value for beam methods so at least one non-EOS continuation can survive. That value is already passed to the top-k, top-p, min-p, typical, epsilon, and eta warpers, but `TopHLogitsWarper` was constructed without it.

As a result, with peaked logits and beam sampling, top-h can keep only the single highest-probability token while the other sampling warpers keep the beam-safe minimum. This PR adds `min_tokens_to_keep` to `TopHLogitsWarper` and passes the generation-level value through, matching the behavior of the other truncation samplers.

The default remains `1`, so existing non-beam top-h behavior is unchanged.

## Tests

Added a regression case to `test_top_h_dist_warper` that checks `TopHLogitsWarper(top_h=0.3, min_tokens_to_keep=2)` keeps two tokens on a highly peaked distribution.

Local:

```bash
PYTHONPATH=src python -m pytest tests/generation/test_logits_process.py -q
# 44 passed
```

## Code Agent Policy

- [X] I confirm that this is not a pure code agent PR.

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [X] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request), Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [X] Did you write any new necessary tests?


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

Replacement PR is now #47262 from a proper fork. It contains the rebased change and current validation; no reopen is needed.
Respect min_tokens_to_keep in TopHLogitsWarper
Author: Incheonkirin
Pull request: yes

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

> This replaces #46643, which I accidentally closed when its source fork was detached. The change has been rebased onto current `main`; the original discussion remains in #46643.

# What does this PR do?

`generate()` computes a `min_tokens_to_keep` value for sampling, using a larger value for beam methods so at least one non-EOS continuation can survive. That value is already passed to the top-k, top-p, min-p, typical, epsilon, and eta warpers, but `TopHLogitsWarper` was constructed without it.

As a result, with peaked logits and beam sampling, top-h can keep only the single highest-probability token while the other sampling warpers keep the beam-safe minimum. This PR adds `min_tokens_to_keep` to `TopHLogitsWarper` and passes the generation-level value through, matching the behavior of the other truncation samplers.

The default remains `1`, so existing non-beam top-h behavior is unchanged.

## Tests

Added a regression case to `test_top_h_dist_warper` that checks `TopHLogitsWarper(top_h=0.3, min_tokens_to_keep=2)` keeps two tokens on a highly peaked distribution.

Local:

```bash
PYTHONPATH=src python -m pytest tests/generation/test_logits_process.py -q
# 44 passed
```

## Code Agent Policy

- [X] I confirm that this is not a pure code agent PR.

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [X] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request), Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [X] Did you write any new necessary tests?

## Validation
- `pytest -q tests/generation/test_logits_process.py::LogitsProcessorTest::test_top_h_dist_warper` (1 passed)

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=47262)
**Latest run:** [29155079939:2](https://github.com/huggingface/transformers/actions/runs/29155079939)
**Result:** `failure` | **Jobs:** 15 | **Tests:** 170,133 | **Failures:** 1 | **Duration:** 14h 46m

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

@gante, could you review this TopHLogitsWarper `min_tokens_to_keep` fix? The only failing CI test is the unrelated Olmo static-cache test; could you rerun that shard?
คิดดี ทำดี เจอแต่สิ่งดี สาธุ 365.ai.th
Author: imgoingbacktheonlything239-ops
Pull request: no
Labels: name: WIP

<!--
Note: Please search to see if an issue already exists for the language you are trying to translate.
-->

Hi!

Let's bring the documentation to all the <iOS-Perplexity-OpenAI-Development>-speaking community 🌐 (currently 0 out of 267 complete)

Who would want to translate? Please follow the 🤗 [TRANSLATING guide](https://github.com/huggingface/transformers/blob/main/docs/TRANSLATING.md). Here is a list of the files ready for translation. Let us know in this issue if you'd like to translate any, and we'll add your name to the list.

Some notes:

* Please translate using an informal tone (imagine you are talking with a friend about transformers 🤗).
* Please translate in a gender-neutral way.
* Add your translations to the folder called `<languageCode>` inside the [source folder](https://github.com/huggingface/transformers/tree/main/docs/source).
* Register your translation in `<languageCode>/_toctree.yml`; please follow the order of the [English version](https://github.com/huggingface/transformers/blob/main/docs/source/en/_toctree.yml).
* Once you're finished, open a pull request and tag this issue by including #issue-number in the description, where issue-number is the number of this issue. Please ping @stevhliu for review.
* 🙋 If you'd like others to help you with the translation, you can also post in the 🤗 [forums](https://discuss.huggingface.co/).

## Get Started section

- [ ] [index.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/index.md) https://github.com/huggingface/transformers/pull/20180
- [ ] [quicktour.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/quicktour.md) (waiting for initial PR to go through)
- [ ] [installation.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/installation.md).

## Tutorial section
- [x] [pipeline_tutorial.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/pipeline_tutorial.md)
- [ ]  [autoclass_tutorial.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/autoclass_tutorial.md)
- [ ]  [preprocessing.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/preprocessing.md)
- [ ]  [training.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/training.md)
- [ ]  [accelerate.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/accelerate.md)
- [ ]  [model_sharing.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/model_sharing.md)
- [ ]  [multilingual.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/multilingual.md)

iOS-Perplexity-OpenAI-Development

Comments:
Hi! I'd like to translate the docs to Hindi (hi). 
I'll start with index.md and quicktour.md. 
Can you add me to the list?"

Hi! I'd like to start the Bengali (bn) translation. I'm a native Bengali speaker from West Bengal, India. I'll start with index.md and follow the TRANSLATING guide. Let me know if a separate issue per language is preferred!