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

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

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

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 | `serge/fix/itf-cae056ff1f13` (pending) |
| `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 | `serge/fix/itf-1c12a6ad471e` (pending) |
| `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 | `serge/fix/itf-1175f61d4596` (pending) |
| `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 |
| `mllama` | output_mismatch — other (8) | 8 | 🚫 no fix |
| `mpt` | other — other (8) | 8 | 🚫 no fix |
| `peft_integration` | other — other (8) | 8 | `serge/fix/itf-3d095811de43` (pending) |
| `recurrent_gemma` | output_mismatch — list output differs (8) | 8 | 🚫 no fix |
| `vision_encoder_decoder` | other — other (8) | 8 | 🚫 no fix |

_Generated 2026-07-11T00:31:25+00:00._

Comments:
Superseded by #47265 — closing this stale nightly integration-failure triage issue. Open PRs stay linked from the current issue.
[serge] Fix 8 integration tests for model `deepseek_v32` failing with `load_error` (other (8))
Author: sergereview[bot]
Pull request: yes

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

## Original CI failure

- Failure group: `1/1: 8 integration tests for model `deepseek_v32` failing with `load_error` (other (8))`
- `tests/models/deepseek_v32/test_modeling_deepseek_v32.py::DeepseekV32IntegrationTest::test_deepseek_v32` [multi-gpu] (load_error, seen 6/7)

<!-- serge-task:integration-failure-triage:sha256:1175f61d4596d7b1d28d6d2b70c8f202eaa5ec18b590fbff51d7e5d4cc056053 -->

Relates to #47265

The `deepseek_v32` integration tests fail during `from_pretrained(..., device_map="auto")` because the checkpoint stores MoE expert weights as separate `gate_proj`/`up_proj` tensors, while the model uses a fused `gate_up_proj`. Loading applies a `WeightConverter` that re-materializes the weights, and when accelerate offloads parameters to disk it must re-save them. Without an `offload_folder` this raises `ValueError`.

The fix adds a per-test temporary `offload_folder` and passes it to every `from_pretrained` call in `DeepseekV32IntegrationTest`. This is the standard pattern for MoE models that need on-the-fly weight conversion under disk offloading.

---
_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` · 72 LLM turns · 69 tool calls · 650.2s · 2231249 in / 9957 out tokens_

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

run-slow: deepseek_v32

<!-- 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=47266)
**Latest run:** [29174475303](https://github.com/huggingface/transformers/actions/runs/29174475303)
**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_47266). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Add TileLang Kernel Support
Author: crownz248
Pull request: no
Labels: name: Feature request

### Feature request

I would like to propose adding support for TileLang kernel in the transformers library. TileLang is a modular approach for writing attention kernels that could provide flexibility and performance benefits.
github link: https://github.com/tile-ai/tilelang
- Add TileLang as an optional attention backend
- Provide configuration options similar to existing attention mechanisms
- Ensure compatibility with existing model architectures
- Add proper multi-GPU support and synchronization

### Motivation

- Enhanced Modularity
TileLang offers a more modular approach to writing attention kernels, making it easier for researchers and developers to modify and optimize the implementation for specific use cases.

- Performance Comparison
Integrating TileLang would allow users to benchmark its performance directly against existing attention implementations, such as Flex Attention and Flash Attention. This would foster a better understanding of how different kernels can impact model performance and efficiency.

- Community Engagement
Supporting TileLang in the Transformers library would attract a broader community of developers interested in optimizing transformer models, thus enhancing collaboration and innovation.

- Flexibility
TileLang's architecture is designed for ease of modification, allowing users to experiment with and refine attention mechanisms more effectively.

### Your contribution

I've experimented with TileLang kernel on transformers models and found it works well in single-GPU scenarios. However, when enabling multi-GPU inference using `device_map='auto'`, I encounter NaN tensors. This may be related to tensor synchronization issues in distributed settings.

I'm willing to help with testing and potentially contributing to the implementation once the multi-GPU synchronization issue is understood and resolved.

I also have 3 questions:
1. Is there any existing plan or roadmap for TileLang integration?
2. Are there specific guidelines for adding new attention backends?
3. What would be the recommended approach for handling multi-GPU synchronization in custom kernels?


Comments:
Hi @crownz248, interesting feature request. I've been following TileLang & the potential for attention kernel optimization. 

I have a few questions to better understand the scope. 

1. Have you traced whether this happens with specific attention implementations (e.g., only with certain head dimensions), or is it universal when using device_map='auto'?
2. Have you run any preliminary benchmarks comparing TileLang vs. Flash Attention on supported GPUs? Understanding where TileLang excels would help justify the integration.

I'd be happy to help with:
- Testing the single-GPU implementation on different model architectures
- Investigating the multi-GPU synchronization issue if you can share more details
- Writing documentation once the integration is complete

Looking forward to seeing where this goes!
Add EDSR and MDSR
Author: IMvision12
Pull request: no
Labels: name: New model

### Model description

EDSR (Enhanced Deep Residual Networks for Single Image Super-Resolution) is for image super resolution, here's the [paper](https://arxiv.org/abs/1707.02921).

### Open source status

- [x] The model implementation is available
- [x] The model weights are available

### Provide useful links for the implementation

Official Implementation https://github.com/sanghyun-son/EDSR-PyTorch and https://github.com/LimBee/NTIRE2017

## Your contribution

I'd like to work on incorporating this architecture into the HuggingFace. Please let me know if you think it's worth adding to huggingface.

@NielsRogge can you review this issue so that I can get started

Comments:
@venkat-natchi


I'm going through the paper and the existing implementation. I will open the PR in few days. 

> I'm going through the paper and the existing implementation. I will open the PR in few days.

That's great, I have already gone through the paper and the architecture and started the implementation!

Sorry, I was away due to festival season here. 
I am done with the paper. Shall I start transforming [this](https://github.com/sanghyun-son/EDSR-PyTorch/blob/9d3bb0ec620ea2ac1b5e5e7a32b0133fbba66fd2/src/model/edsr.py) one into the HuggingFace model standards?

Go ahead and let me know if you need any help; I will be adding the MDSR model to the hub, and I believe the code should be similar to this [Swin2sr](https://github.com/huggingface/transformers/pull/19784) PR also we can use it for reference.

Sure, thanks

Can we add both EDSR and MDSR in this PR?

No, I guess a separate PR is required.

Hello, can I work on this issue? Although I'm new to open-source contributions, I've worked on super-resolution models in the past and I was wondering why HuggingFace did not have these. I am familiar with PyTorch.

Thanks @asrimanth for the interest. 
I have an active PR going on for this issue.
#19952 

Kindly  leave your comments there if you could.
Feature request: Add EfficientViT-SAM (efficientvitsam) to Transformers
Author: masoudpz
Pull request: no
Labels: name: Feature request

### Feature request

[EfficientViT-SAM](https://github.com/mit-han-lab/efficientvit) combines MIT’s EfficientViT encoder with the SAM-style prompt encoder and mask decoder. It offers a lighter, faster alternative to ViT-based SAM for interactive segmentation while staying close to the same prompting and mask-decoding workflow.

Today, users who want this stack in the Hugging Face ecosystem must rely on custom code or the upstream repo. First-class support in Transformers would:

Enable from_pretrained on official or community checkpoints (e.g. mit-han-lab/efficientvit-sam and converted .pt weights).


### Motivation

Provide a single API aligned with existing SAM-style models (AutoModel, processors, post_process_masks).
Improve discoverability and CI-tested parity with upstream preprocessing and architecture where feasible.

### Your contribution

Add efficientvitsam model code: configuration, image processing, processor, and PyTorch modeling consistent with upstream efficientvit/applications/efficientvit_sam/.
Register the model in auto classes and document it in the model hub docs.
Include a conversion path from official checkpoints and tests (including optional slow parity checks against the upstream predictor where appropriate).

Comments:
@masoudpz I'm interested in contributing to this feature request. I'd like to work on adding EfficientViT-SAM support to Transformers. 

If no one is actively working on it, I'd be happy to take it on and start planning the feature and implementation approach. Any guidance from the maintainers on the expected implementation approach would be appreciated.
AutoModel loading fails with ROCm when model has custom CUDA kernels
Author: hakuba-pamu
Pull request: no

Models with custom CUDA extensions (e.g., flash-attention) fail to load on ROCm. The `is_available()` check passes but the actual kernel launch fails.

Expected: graceful fallback to standard attention.
Actual: RuntimeError at inference time.

ROCm 6.0, MI210

Comments:
Hmmn, maybe we should tweak those checks so they only pass when the device actually supports the ops? cc @ivarflakstad maybe, but if you're not confident in the fix let me know and I can try it

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

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md) are likely to be ignored.
[ExecuTorch] convert_and_export_with_cache fails for vision-language and audio models
Author: ananyajoshi0203-cpu
Pull request: no

## Description

`convert_and_export_with_cache` and `TorchExportableModuleWithStaticCache.forward` 
currently only support text-only models. Attempting to export a vision-language model 
(e.g. LLaVA, PaliGemma) or audio model (e.g. Whisper) fails because:

1. `TorchExportableModuleWithStaticCache.forward` does not accept or forward 
   `pixel_values` or `input_features` — the vision/audio branches of the model 
   are invisible to the export trace
2. `convert_and_export_with_cache` hardcodes example inputs as a single token tensor, 
   which is invalid for multimodal models

This was acknowledged with a TODO comment at line 799:
> "The default inputs only work for text models. We need to add support for vision/audio models."

## Proposed fix

- Add `pixel_values` and `input_features` as optional params to `forward()`, 
  passed through only when non-`None` (text-only paths unaffected)
- Add `example_modality_inputs` param to `convert_and_export_with_cache()` 
  with auto-inference from model config (`vision_config` → `pixel_values`, 
  `num_mel_bins` → `input_features`)

I have a working implementation with tests ready. Happy to open a PR if this 
direction looks good to maintainers.

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

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md) are likely to be ignored.
StoppingCriteria for Repetition
Author: Vipitis
Pull request: no
Labels: name: Feature request

### Feature request

similar to repetition_penalty for generation config, but as a stopping criteria.


### Motivation

(small?) models tend to generated endless loops of the same few tokens, or a combination where they only increase like a single digit.  (could not find any similar FRs)

I run into this quite a lot when doing evaluation runs (with greedy decoding) for code completion tasks. here is a screenshot of multiple generations saved to a file. the blocks of repetition can easily be spotted. 
![image](https://github.com/user-attachments/assets/305123b0-5623-4c83-af2c-ab0ff16dd494)

Having a stopping criterion that detects such behaviour would massively speed up evaluation runs, since generation could stop early and not reach the `max_new_token` set. Some parameters might be helpful to expose like number of repetitions, and n-gram overlap for example.

### Your contribution

I am happy to contribute with a PR myself, but will not find the time to do so in the next ~6-8 weeks. It doesn't look straight forward, but I am also not too familiar with the deeper parts of the generation code - so it might take me a while.

Comments:
Hey @Vipitis ! A small question, can we use only repetition penalty to prevent this instead of forcing to stop when an ngram is repeated?

cc @gante 

> can we use only repetition penalty

Likely yes in most practical settings. But in the case of runnings generation for eval benchmarks, some require greedy decoding. Using any of the generation config parameters impacts the tokens you decode, therefore adding variables to the experiment. 
Stopping criteria is just that, it stops early when the generation has already failed. There is a non zero chance that the model somehow recovers and still completes a valid function, but I have not observed that yet. 

Hey @Vipitis 👋 Thank you for opening this issue!

It does make sense to save compute cycles when we have high confidence that the output won't improve -- repetition is one of those cases. I'd gladly accept a PR that adds that StoppingCriteria :) 

(suggestion: we can add a `stop_at_repeated_ngram_size` flag, or something similar, to `GenerationConfig`)

Implemented in #47271. The PR is explicitly disclosed as AI-generated and is based on three days of implementation, testing, and benchmarking in our Cohere batch-inference project: https://github.com/AliOsm/cohere-transcribe-arabic-batch-inference. It includes the production ablation results, exact criterion microbenchmarks, documentation, and focused/integration tests.
[serge] integration failure triage - 2026-07-11
Author: github-actions[bot]
Pull request: no

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

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

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 | `serge/fix/itf-cae056ff1f13` (pending) |
| `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 | 🚫 no fix |
| `dac` | output_mismatch — tensor values differ (6), other (6) | 12 | ⚠️ task failed |
| `edgetam` | import_or_config — other (12) | 12 | #47122 |
| `glm46v` | other — other (12) | 12 | ⚠️ task failed |
| `minimax_m3_vl` | load_error — other (12) | 12 | ⚠️ task failed |
| `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 | ⚠️ task failed |
| `glm_ocr` | output_mismatch — list output differs (10) | 10 | ⚠️ task failed |
| `deepseek_v32` | load_error — other (8) | 8 | `serge/fix/itf-1175f61d4596` (pending) |
| `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 | ⚠️ task failed |
| `mllama` | output_mismatch — other (8) | 8 | ⚠️ task failed |
| `mpt` | other — other (8) | 8 | 🚫 no fix |
| `peft_integration` | other — other (8) | 8 | ⚠️ task failed |
| `recurrent_gemma` | output_mismatch — list output differs (8) | 8 | ⚠️ task failed |

_Generated 2026-07-12T00:32:32+00:00._

Comments:
Superseded by #47279 — closing this stale nightly integration-failure triage issue. Open PRs stay linked from the current issue.
[serge] Fix 12 integration tests for model `minimax_m3_vl` failing with `load_error` (other (12))
Author: sergereview[bot]
Pull request: yes

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

## Original CI failure

- Failure group: `1/1: 12 integration tests for model `minimax_m3_vl` failing with `load_error` (other (12))`
- `tests/models/minimax_m3_vl/test_modeling_minimax_m3_vl.py::MiniMaxM3VLIntegrationTest::test_long_context_needle_token_match` [multi-gpu] (load_error, seen 6/7)

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

Relates to #47279

The `MiniMaxM3VLIntegrationTest` integration tests fail during `from_pretrained(..., device_map="auto")` because accelerate needs to re-save converted weights when the auto device map offloads layers to disk. The MiniMax-M3-MXFP8 checkpoint uses internal weight conversions (e.g. per-expert merging) that differ from the on-disk format, so the loader requires an explicit `offload_folder`.

Provide a temporary `offload_folder` in `_load_model` and clean it up in `tearDown`. This is a test-only fix; no model code is changed.

Note: the repo normalizer currently reports unrelated pre-existing failures in `modeling_rules_doc` and `docstrings` (`transformers.models.tipsv2` / `Tipsv2Config` import), which are outside this failure group's scope.

---
_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` · 72 LLM turns · 69 tool calls · 232.6s · 2248956 in / 10655 out tokens_

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

run-slow: minimax_m3_vl

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

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

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