noamaanMulla-03/transformers-issues huggingface dataset:
[serge] integration failure triage - 2026-07-12
Author: github-actions[bot]
Pull request: no

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

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

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 | ⚠️ task failed |
| `gemma` | output_mismatch — list output differs (14) | 14 | ⚠️ task failed |
| `edgetam` | import_or_config — other (12) | 12 | #47122 |
| `glm46v` | other — other (12) | 12 | `serge/fix/itf-eeafa510c34c` (pending) |
| `hunyuan_vl` | output_mismatch — list output differs (8), other (4) | 12 | 🚫 no fix |
| `minimax_m3_vl` | load_error — other (12) | 12 | `serge/fix/itf-dcad4640523f` (pending) |
| `diffusion_gemma` | output_mismatch — tensor values differ (6), list output differs (4) | 10 | ⚠️ task failed |
| `gemma3` | output_mismatch — list output differs (8), other (2) | 10 | ⚠️ task failed |
| `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 | ⚠️ task failed |
| `falcon_mamba` | output_mismatch — other (6), list output differs (2) | 8 | #47124 |
| `grounding_dino` | output_mismatch — tensor values differ (6), other (2) | 8 | ⚠️ task failed |
| `higgs_audio_v2` | output_mismatch — tensor values differ (8) | 8 | 🚫 no fix |
| `mamba2` | OOM — other (8) | 8 | `serge/fix/itf-2c9bcdbaeccf` (pending) |
| `mllama` | output_mismatch — other (8) | 8 | ⚠️ task failed |
| `mpt` | other — other (8) | 8 | 🚫 no fix |
| `peft_integration` | other — other (8) | 8 | ⚠️ task failed |

_Generated 2026-07-13T00:35:30+00:00._

Comments:
Superseded by #47309 — closing this stale nightly integration-failure triage issue. Open PRs stay linked from the current issue.
Fix StaticLayer.get_seq_length return type annotation (#45987)
Author: Sanjays2402
Pull request: yes

Fixes #45987.

`StaticLayer.cumulative_length` is initialized as a shape-(1,) `torch.Tensor` (so that in-place `.add_()` updates stay `torch.compile`-friendly), and `StaticLayer.get_seq_length()` returns it directly. The current `-> int` annotation lies about that.

Per @Rocketknight1's [comment on the issue](https://github.com/huggingface/transformers/issues/45987):

> I think this is mostly just a type-hint bug, right? There isn't really much difference between a tensor with shape `(1,)` and a 0-dim tensor, they'll both broadcast with any other tensor and work with `item()` etc. Also, we generally want to avoid `item()` where possible because it causes a CUDA sync. So maybe just make the return type `int | Tensor` or something but leave the rest of the code alone?

This PR does exactly that — minimal annotation-only change:

- `CacheLayerMixin.get_seq_length` abstract: `-> int` → `-> int | torch.Tensor`
- `StaticLayer.get_seq_length`: `-> int` → `-> int | torch.Tensor`, plus a docstring note explaining why a tensor is returned.

No runtime behavior change. No `.item()` calls added. Other concrete `get_seq_length` overrides (`DynamicLayer`, `StaticSlidingWindowLayer`, `QuantizedLayer`, ...) already return ints and don't need touching.

The four earlier PRs for this issue (#46005, #46010, #46081, #45997) all attempted heavier rewrites that added `.item()` or restructured `cumulative_length`, which is the opposite of the requested fix. This PR sticks to the maintainer-specified shape.

## Before submitting

- [x] This PR fixes a typing issue and links to the existing issue (#45987).
- [x] Did you make sure to update the documentation with your changes? (Docstring updated to reflect actual return type.)
- [x] Did you write any new necessary tests? Not needed — annotation-only change with no runtime behavior delta.

## Who can review?

@Rocketknight1 (you commented on #45987 with the requested approach)

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

@Rocketknight1 merge failed, could you please have a look?

Putting it back in!
[serge] Fix 12 integration tests for model `glm46v` failing with `other` (other (12))
Author: sergereview[bot]
Pull request: yes

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

## Original CI failure

- Failure group: `1/1: 12 integration tests for model `glm46v` failing with `other` (other (12))`
- `tests/models/glm46v/test_modeling_glm46v.py::Glm46VIntegrationTest::test_small_model_integration_test` [multi-gpu] (other, seen 6/7)

<!-- serge-task:integration-failure-triage:sha256:eeafa510c34cc711112e62fad1875f58e942645f41dfca2fe93c60c0b1084ee8 -->

Relates to #47279

The `glm46v` integration tests fail because `input_ids` reaches the text embedding layer with a floating-point dtype (bfloat16/float16) instead of an integer dtype, causing `nn.Embedding` to raise a type error.

This happens when the model is loaded with `dtype="auto"`/`torch.float16` and `device_map="auto"`; the indices tensor is cast to the model's dtype before the embedding lookup.

Fix the issue at the source by casting `input_ids` to `torch.long` in `Glm4vModel.forward`. `Glm46VModel` inherits from `Glm4vModel`, so the generated `modeling_glm46v.py` will pick up the fix via `make fix-repo`.

---
_This change was produced automatically by serge from a CI failure report. The patch was generated by an LLM and applied by serge; review before merging._

_serge `v0.1.0` · model: `moonshotai/Kimi-K2.7-Code` · 70 LLM turns · 67 tool calls · 605.0s · 2324170 in / 49492 out tokens_

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_47281). 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: glm46v, glm4v

<!-- 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=47281)
**Latest run:** [29216204931:1](https://github.com/huggingface/transformers/actions/runs/29296889265)
**Result:** `failure` | **Jobs:** 2 | **Tests:** 11 | **Failures:** 1 | **Duration:** 57s

<!-- ci-dashboard-recap:end -->
Update AMD CI runner groups to amd-mi300
Author: Abdennacer-Badaoui
Pull request: yes

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

Switch the AMD daily CI runner groups from hfc-amd-mi300 to amd-mi300-{1,2}gpu.

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

<!-- ci-dashboard-recap:end -->
Misleading synced_gpus warning message in continuous batching
Author: Partha-Shankar
Pull request: no
Labels: name: bug

### System Info

- `transformers` version: 5.14.0.dev0
- Platform: Windows-11-10.0.26200-SP0
- Python version: 3.12.7
- Huggingface_hub version: 1.22.0
- Safetensors version: 0.8.0
- Accelerate version: 1.14.0
- Accelerate config: 	not found
- DeepSpeed version: not installed
- PyTorch version (accelerator?): 2.12.1+cpu (NA)
- Using distributed or parallel set-up in script?: No

### Who can help?

@remi-or @ArthurZucker @McPatate

### Information

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

When generating using continuous batching (by passing `cache_implementation="paged"`), if you pass `synced_gpus=True` to the model's `generate()` method, a misleading warning is logged.

The warning in `src/transformers/generation/utils.py` reads:
```python
logger.warning(f"synced_gpus is not ignored for continuous batching. Got {synced_gpus = }")
```

Because `synced_gpus` is in fact ignored for continuous batching, the warning should say "is ignored" rather than "is not ignored".

Minimal reproduction using `hf-internal-testing/tiny-random-gpt2`:

```python
import torch
from unittest.mock import patch
from transformers import AutoConfig, AutoModelForCausalLM

config = AutoConfig.from_pretrained("hf-internal-testing/tiny-random-gpt2")
model = AutoModelForCausalLM.from_config(config)
input_ids = torch.tensor([[1, 2, 3]])

with patch.object(model, "generate_batch", return_value={}):
    model.generate(input_ids, synced_gpus=True, cache_implementation="paged")
```

This logs:
```
synced_gpus is not ignored for continuous batching. Got synced_gpus = True
```

### Expected behavior

The warning message should state that synced_gpus is ignored for continuous batching, not that it "is not ignored." Specifically, in src/transformers/generation/utils.py:

logger.warning(f"synced_gpus is ignored for continuous batching. Got {synced_gpus = }")

Comments:
PPFormulaNet training-loss bug
Author: sharmax-vikas
Pull request: no
Labels: name: bug

### System Info

PPFormulaNet training-loss bug — ForCausalLMLoss incorrectly shifts labels in encoder-decoder model
The problem: PPFormulaNetForConditionalGeneration.forward() uses self.loss_function() (line 491 in modular_pp_formulanet.py) which maps to ForCausalLMLoss. ForCausalLMLoss internally shifts labels left by 1 (labels[..., 1:]), but PPFormulaNet is an encoder-decoder model where the logits are already aligned with labels — no shift is needed.
This means the model trains against misaligned labels, losing the last target token.
Where:
# modular_pp_formulanet.py, line 491
loss = self.loss_function(
    logits=logits, labels=labels, vocab_size=self.config.text_config.vocab_size, **kwargs
)

The fix (same pattern as Florence2 after #46898):
loss = self.loss_function(
    logits=logits, labels=labels, vocab_size=self.config.text_config.vocab_size,
    shift_labels=labels, **kwargs
)

Passing shift_labels=labels tells ForCausalLMLoss to skip its internal shift, keeping labels aligned with logits.
Context: Florence2 (which PPFormulaNet inherits from) was already fixed in PR #46898 with this same pattern, but PPFormulaNet overrides forward() so the fix didn't propagate. eliaghazal also flagged PPFormulaNet as potentially affected in PR #47090 discussion, but no one has filed or fixed it yet.


### Who can help?

_No response_

### Information

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

.

### Expected behavior

.

Comments:
Streaming and assisted decoding strategy for pipeline OR clearer understanding of pipelines to manually apply tasks
Author: gidzr
Pull request: no
Labels: name: Feature request

### Feature request

Currently looking to get a number of non-pipeline functions with pipelines
- Decoder strategies
- Assisted decoding
- Streaming output
etc

**Alternately**, if I can adopt the non-pipeline transformer approach with tokenizer act more pipeline'ish, that'd also be good. Specifically, what are the underlying changes that happen when selecting a task for pipeline? Eg. if I select 'text-generation' as a pipeline, what's that actually doing (so can apply the same thing to the non-pipeline approach)

If for example pipeline_task = "text-generation", does this autoconfigure the model and tokenizer config, like sampling, temperature, beams, top-k, top-p, max_new_tokens?... What does the pipeline task actually do to the underlying model? If I knew this, I wouldn't need the above features for pipelines.

### Motivation

I want to have all the features from all the approaches available from the one approach

### Your contribution

Nothing yet

Comments:
Hi there! Good news: you actually don't need to adopt the non-pipeline approach to get these features.

The pipeline is designed to be highly flexible. When you instantiate a text-generation pipeline, it doesn't hardcode or lock down the model's generation config. Inside the pipeline's _forward method, any extra keyword arguments you pass when calling the pipeline are passed directly down to model.generate(**generate_kwargs).

This means you can use all the non-pipeline features (Streaming, Assisted Decoding, Top-K, etc.) natively in the pipeline just by passing them as arguments!

Examples:

Decoder Strategies:



pipe("Hello", max_new_tokens=50, do_sample=True, top_k=50, temperature=0.7)
Streaming Output:



from transformers import TextStreamer
streamer = TextStreamer(tokenizer)
pipe("Hello", streamer=streamer)
Assisted Decoding:



pipe("Hello", assistant_model=small_model)
The pipeline essentially acts as a convenience wrapper around tokenizer -> model.generate -> decode. So you get the convenience of the pipeline and the full feature set of model.generate(). Hope this helps!
piepline strming info added in md file
Author: Prakhar54-byte
Pull request: yes
Labels: name: Code agent slop

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

Add docs to  explain that users are currently confused about whether pipelines support streaming and decoding strategies. Mention that you added a short section to the pipeline tutorial to show how to pass **kwargs directly to the generator.
Fixes #26316 .

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

<!-- ci-dashboard-recap:end -->
stable diffusion in tensorflow 
Author: deborshi-web
Pull request: no

I would like to share my idea from my perspective 

Translation of all code in hugging face to tensorflow and Implementing Stable Diffusion in TensorFlow—primarily via the KerasCV Stable Diffusion API—provides industry-leading execution speeds, production-ready serving architectures, and seamless mobile deployment capabilities. Is it possible??

Comments:
We dropped TF support some time ago. It's certainly possible, but we probably won't maintain it so you might have to do it in your own fork 😅 

> We dropped TF support some time ago. It's certainly possible, but we probably won't maintain it so you might have to do it in your own fork 😅 

Can I just copy codes of stable diffusion only from hugging face then translating to tensorflow and put it on my own repo?? 

Yes, Transformers is open-source under the Apache licence, so you're free to copy and modify it in your own repo!
Fix misleading synced_gpus warning in continuous batching
Author: vakudo
Pull request: yes

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

Fixes #47276.

When generating with continuous batching (`cache_implementation="paged"`), passing `synced_gpus` logs a warning that states the opposite of what actually happens:

```python
# others are ignored
if synced_gpus is not None:
    logger.warning(f"synced_gpus is not ignored for continuous batching. Got {synced_gpus = }")
```

`synced_gpus` **is** ignored for continuous batching — the `# others are ignored` comment immediately above says so, and the surrounding branch handles the other unsupported arguments the same way. The message should read "is ignored".

This changes only the warning string; there is no behavior change.

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

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

This closed after rebase, which means the fix was probably already in the codebase via a different PR

Closing — this was already addressed by #47158, which is now on main.
Route chat management calls to the service root (#47138)
Author: dhruv7477
Pull request: yes

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

# What does this PR do?

Fixes #47138

`transformers chat` reuses `base_url` for the serve management endpoints. With the documented `base_url` ending in `/v1`, the health check requests `/v1/health` and model loading posts to `/v1/load_model`. The serve app mounts `/health`, `/load_model` and `/reset` at the service root; only the OpenAI-compatible inference API lives under `/v1`. Ran the numbers on both sides to be sure: `server.py` registers the management routes at root, and `chat.py` builds both management URLs from the raw `base_url`.

The fix derives a management base url by stripping a trailing `/v1` segment and routes `check_health` and `print_model_load` through it, while the `AsyncInferenceClient` keeps the full `base_url` for inference. Deliberately boring on the edges: a `base_url` without `/v1` behaves exactly as before, and a `/v1` behind a reverse-proxy prefix keeps the prefix (`https://host/proxy/v1` manages at `https://host/proxy`).

Tests cover the url derivation and both management calls, mocked, so they run anywhere with no model download.

## Who can review?

CLI / serving: @Rocketknight1

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

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

cc @sunmarc @remi-or @LysandreJik for serving, see also the original issue at #47138!
Fix PPFormulaNet training loss: prevent incorrect label shift in ForCausalLMLoss
Author: sagnikai
Pull request: yes

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

ForCausalLMLoss internally shifts labels left by 1 (labels[..., 1:]) when shift_labels is not provided. However, PPFormulaNet is an encoder-decoder model where logits are already aligned with labels — no shift is needed. This causes the model to train against misaligned labels, losing the last target token.

This fix passes shift_labels=labels to ForCausalLMLoss, telling it to skip the internal shift. This matches the same pattern used by Florence2 (fixed in #46898), which PPFormulaNet inherits from but overrides orward().

Fixes #47317.

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

run-slow: pp_formulanet

<!-- 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=47319)
**Latest run:** [29336073721](https://github.com/huggingface/transformers/actions/runs/29336073721)
**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 -->
[docs] MTP support
Author: stevhliu
Pull request: yes

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

Adds docs for enabling MTP on supported models (see https://github.com/huggingface/transformers/pull/46229)

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

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