noamaanMulla-03/transformers-issues huggingface dataset:
AMD quark class not updated
Author: debasisdwivedy
Pull request: no
Labels: name: bug

### System Info

- `transformers` version: 5.13.1
- Platform: Linux-6.8.0-1058-gcp-x86_64-with-glibc2.39
- Python version: 3.13.13
- Huggingface_hub version: 1.23.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+cu130 (CUDA)
- Using distributed or parallel set-up in script?: <fill in>
- Using GPU in script?: <fill in>
- GPU type: Tesla T4

### Who can help?

Hi ,

The quantization config for AMD class points to an older release and needs to be updated.
File : `src/transformers/utils/quantization_config.py`

Previous versions of Quark had the config as `from quark.torch.quantization.config.config import Config`, which has been changed to `from quark.torch.quantization.config.config import QConfig`

Regards

### Information

- [x] The official example scripts
- [x] My own modified scripts

### Tasks

- [x] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

def main():
    evaluation_tracker = EvaluationTracker(
        output_dir="./results",
        save_details=True
    )

    pipeline_params = PipelineParameters(
        launcher_type=ParallelismManager.ACCELERATE,
        custom_tasks_directory=None,  # Set to path if using custom tasks
        # Remove the parameter below once your configuration is tested
        # max_samples=10
    )

    model_config = TransformersModelConfig(
        model_name="", #Quark quantized folder path
        device="cuda"
    )

    task = ""

    pipeline = Pipeline(
        tasks=task,
        pipeline_parameters=pipeline_params,
        evaluation_tracker=evaluation_tracker,
        model_config=model_config,
    )

    pipeline.evaluate()
    pipeline.save_and_push_results()
    pipeline.show_results()

### Expected behavior

Should load the quantized model, but we get error: "Unable to Import from quark.torch.quantization.config.config import Config"

Comments:
New quark install `pip install amd-quark`
ASR pipeline: unconditional torchcodec import crashes on broken torchcodec installs
Author: evnsnclr
Pull request: no

### System Info

- transformers 5.12.1, torch 2.10.0, torchcodec 0.14.0 (installed as a dependency of pyannote-audio 4.0.7)
- macOS 15.6 (arm64), Python 3.11.12
- Same failure mode applies to any platform where the installed torchcodec cannot be imported.

### Reproduction

`AutomaticSpeechRecognitionPipeline.preprocess` does:

```python
if is_torchcodec_available():
    import torchcodec
```

`is_torchcodec_available()` is a package-metadata check (is torchcodec installed), not an importability check. torchcodec wheels are binary-tied to a specific torch release but declare no torch requirement in their metadata (`importlib.metadata.requires("torchcodec")` has no torch entry), so resolvers routinely produce installed-but-unimportable combinations — e.g. torch 2.10.0 + torchcodec 0.14.0, a pairing pip/uv will happily create today via `pyannote-audio` → `torchcodec`. The bare import then raises `OSError` and kills **every** pipeline call — including plain file-path and `{"raw": ...}` inputs that never needed torchcodec, since the file-path branch decodes with `ffmpeg_read`.

Repro on macOS arm64 / Python 3.11:

```bash
pip install transformers torch==2.10.0 torchcodec==0.14.0
python -c "
from transformers import pipeline
pipe = pipeline('automatic-speech-recognition', model='openai/whisper-tiny')
pipe('any.wav')
"
```

fails with:

```
OSError: Could not load this library: .../torchcodec/libtorchcodec_core8.dylib
(Symbol not found: _torch_dtype_float4_e2m1fn_x2)
```

raised from `automatic_speech_recognition.py`'s `preprocess` at the `import torchcodec` line.

Downstream real-world impact: this currently breaks 100% of fresh installs of `insanely-fast-whisper` (see https://github.com/Vaibhavs10/insanely-fast-whisper/pull/283, which works around it by monkeypatching `is_torchcodec_available` when the import fails).

### Expected behavior

torchcodec is only needed to accept `torchcodec.decoders.AudioDecoder` inputs. A broken torchcodec install should not take down unrelated input types. Suggested fix: wrap the import in `try/except (ImportError, OSError)` and treat torchcodec as unavailable (optionally with a one-time warning). I'm happy to send a PR.

(Complementary fix on the torchcodec side would be publishing torch version bounds in wheel metadata; I can open that issue with pytorch/torchcodec as well.)


Comments:
I think this makes more sense as a torchcodec version bounds fix, yeah. We don't want to defensively patch against environment edge cases like this.

Hi @Rocketknight1 I would love to take on this and apply the version bound fix. The plan is to add a check inside is_torchcodec_available(), so incompatible versions are treated as unavailable. This would also avoid the try/except blocks around the import. 

We already reference a floor of 0.3.0 in audio_utils.py, but since this being a compatibility mismatch between torch and torchcodec, should we try to detect if their versions actually match up, or just keep it simple and pin a tested range? Please let me know if I can contribute to this fix.
[docs] DeepGEMM requirements
Author: stevhliu
Pull request: yes

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

Adds docs for how Transformers finds the toolkit (`CUDA_HOME → CUDA_PATH → nvcc on PATH → /usr/local/cuda`) and set `CUDA_HOME` if it isn't found (see #47154)

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=47324)
**Latest run:** [29346147440](https://github.com/huggingface/transformers/actions/runs/29346147440)
**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_47324). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Add RoMa keypoint matcher
Author: srishtiii28
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47082)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47082)
<!-- ci-dashboard-badge:end -->

# What does this PR do?

Adds RoMa i.e. Robust Dense Feature Matching ([https://arxiv.org/abs/2305.15404](https://arxiv.org/abs/2305.15404)) as a keypoint-matching model. 

Fixes #36718

Following up on [comment](https://github.com/huggingface/transformers/issues/36718#issuecomment-4831878441) by maintainer.  I checked open PRs/issues and none add RoMa

I have used AI assistance to go through open PRs and understand the codebase better along with writing better documentation. 

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

run-slow: auto, roma

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

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

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

the converted weights are ready, I'll upload them to the Hub once we settle the repo ids
:rotating_light: Fix GPTBigCode and GPTNeoX for the Transformers modelling backend for vLLM
Author: hmellor
Pull request: yes

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

- Adds a remapping from `embed_out` to `lm_head` for GPTNeoX
- Adds `_supports_attention_backend = True` to GPTBigCode because it does

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

<!-- 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=47198)
**Latest run:** [29238308208:1](https://github.com/huggingface/transformers/actions/runs/29314935790)
**Result:** `failure` | **Jobs:** 15 | **Tests:** 171,041 | **Failures:** 1 | **Duration:** 23m 48s

<!-- ci-dashboard-recap:end -->
Fix MoE expert decompression for non-32-divisible bit widths
Author: KKothuri
Pull request: yes

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

## What does this PR do?

`DecompressExperts.convert` (in `integrations/compressed_tensors.py`) rebuilds each MoE expert's unpacked input dimension as `packed_cols * (32 // num_bits)`. `compressed-tensors` uses **dense** bit-packing, so this reconstruction is only exact when `num_bits` divides 32 (i.e. 4-bit and 8-bit). For 3/5/6/7-bit weights it under-counts.

Concretely, a 3-bit `down_proj` stored as `weight_packed` of shape `(2048, 48)` reconstructs an input dim of `48 * (32 // 3) = 48 * 10 = 480`, whereas the true dim is `512`. The experts then decompress to the wrong shape and loading fails with:

```
RuntimeError: contraction dimension of mat_a and mat_b must match
```

from `torch._grouped_mm`. 4-bit and 8-bit checkpoints are unaffected because 8 and 4 divide 32 evenly.

### Fix

The checkpoint already stores an exact per-expert `weight_shape` (`(out-dim, in-dim)`), and it is already routed into `convert` via the `.weight_shape$` source pattern in `quantizer_compressed_tensors.py`. This PR uses that stored shape, and falls back to the packed-tensor reconstruction only when it is missing/empty (e.g. left empty on most ranks under TP/EP sharding — the case the previous code was written for).

### Testing

Verified on a 3-bit (W3A16) AWQ-quantized MoE checkpoint (`GlmMoeDsaForCausalLM`):

- **Before:** loading crashes with the `_grouped_mm` contraction error above.
- **After:** loads successfully; perplexity **1.0002** vs. **1.0000** for the bf16 base on the same text.

4-bit and 8-bit checkpoints load identically before and after (the stored shape matches the old reconstruction for those bit widths).

AI assistance was used for this change; every line was reviewed and the tests above were run.

## Before submitting
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request)?
- [x] Did you make sure to update the documentation with your changes? (n/a — bug fix, no API change)
- [ ] Did you write any new necessary tests? (happy to add a regression test if maintainers prefer)

## Who can review?

Quantization / compressed-tensors: @SunMarc @MekkCyber

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=47315)
**Latest run:** [29320067190:2](https://github.com/huggingface/transformers/actions/runs/29320067190)
**Result:** `success` | **Jobs:** 15 | **Tests:** 169,249 | **Failures:** 0 | **Duration:** 13h 32m

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

Not sure how significant it is but could be real, cc @sunmarc for quants maybe?
[docs] Improve CLI copy
Author: stevhliu
Pull request: yes

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

Improves CLI copy to be more clear, consistent, brief, and actionable (adapted from https://github.com/vercel/vercel/blob/main/packages/cli/.agents/skills/cli-ux/references/copy.md). See some selected examples below:

| Before | After |
|---|---|
| When not using an editable install, the path to the Transformers repo. | Path to the Transformers repo when not using an editable install |
| Enable permissive CORS. | Allow cross-origin requests from any origin |
| Seconds before idle model is unloaded. Ignored when force_model is set. | Unload idle models after this many seconds; ignored with a fixed model |
| Whether or not to allow for custom models defined on the Hub in their own modeling files. Use only if you've reviewed the code as it will execute on your local machine | Allow custom model code from the Hub to run locally after you've reviewed it |
| Path to a local generation config file or to a HuggingFace repo containing a `generation_config.json` file. Other generation settings passed as CLI arguments will be applied on top of this generation config. | Local path or Hub repo containing `generation_config.json`; CLI generation settings override it |
| When not using an editable install, the path to the Transformers repo. | Path to the Transformers repo when not using an editable install |

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

<!-- ci-dashboard-recap:end -->
Add LocalMode to `awesome-transformers.md`
Author: MuathJ
Pull request: yes

This PR adds [LocalMode](https://github.com/LocalMode-AI/LocalMode) to `awesome-transformers.md`.

LocalMode is a local-first AI toolkit (MIT) that runs models entirely in the browser — no servers, no API keys, and data never leaves the device. Transformers.js is one of its core inference backends (alongside WebLLM, wllama, LiteRT, MediaPipe, and Chrome Built-in AI), wrapped behind a zero-dependency core that adds embeddings, vector search, RAG, and agents, plus React hooks and a shadcn-compatible UI registry.

- Repo: https://github.com/LocalMode-AI/LocalMode
- Docs: https://localmode.dev
- Live demos (run entirely in your browser): https://localmode.ai/blocks

The list's README invites PRs adding relevant projects, and Transformers.js — which LocalMode builds on — is already featured. Thanks for maintaining this list!


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/29382344687) for the exact violations.

A maintainer can review and manually approve CI if a finding is a false positive.
[Nit] Add expectations for gemma4 tests on H100
Author: remi-or
Pull request: yes

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

This PR adds expectations for the integration tests of gemma4 on H100.

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

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

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47311)
**Latest run:** [29298641319:1](https://github.com/huggingface/transformers/actions/runs/29383312244)
**Result:** `success` | **Jobs:** 2 | **Tests:** 22 | **Failures:** 1 | **Duration:** 1m 47s

<!-- ci-dashboard-recap:end -->
[Nit] Add kernels_fallback_ok kwarg to is_flash_attn_N_available
Author: remi-or
Pull request: yes

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

This PR adds the kwarg `kernels_fallback_ok` to the `is_flash_attn_2_available` and `is_flash_attn_3_available` functions. The kwarg has the default value `False`, so the behavior of the function does not change. But it allows an user to check if `flash` would be available at runtime, either through the official package or through `kernels`. 

This is quite practical because in CB, we want to be able to check if we can `flash` instead of the original or default `attn_implementation`, and adding a new function to do this seemed bad design. Plus, it means we can simplify `require_flash_attn` because this is the exact check it performs.

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

<!-- ci-dashboard-recap:end -->
Fix save_pretrained with offloading and weight conversions
Author: Cyrilvallez
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47018)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47018)
<!-- ci-dashboard-badge:end -->

# What does this PR do?

As per the title. Currently, since offloaded weights are on meta device and reverse conversions happens BEFORE we reload them from disk, the resulting converted tensors are on meta as well, and then we will usually fail when trying to load them back from the model, since they changed name.
Since we cannot load everything back to cpu at the beginning with offloading (we have a constrained cpu environment usually, otherwise we would not offload), the best is to skip conversion at the beginning, load all params of a given file shard to cpu, and reverse-convert only this shard before starting the next. This is however not fullproof for one-weight-to-many conversions, because the reverse is many-weight-to-one, meaning we need several weights to be able to perform the conversion, and they may not live all in the same shard if we are unlucky with how the shards were created. In those cases, we raise a nice and clear error, as we cannot do better without probably overloading the memory compl,etely anyway.

Supersedes https://github.com/huggingface/transformers/pull/46902

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_47018). 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=47018)
**Latest run:** [28581147185:1](https://github.com/huggingface/transformers/actions/runs/28581147185)
**Result:** `success` | **Jobs:** 13 | **Tests:** 46,177 | **Failures:** 0 | **Duration:** 16h 9m

<!-- ci-dashboard-recap:end -->
[Offloading] Cannot save disk-offloaded `Qwen3-VL-32B-Instruct`
Author: kylesayrs
Pull request: no
Labels: name: bug

### System Info

- `transformers` version: 5.13.0.dev0
- Platform: Linux-5.14.0-611.41.1.el9_7.x86_64-x86_64-with-glibc2.34
- Python version: 3.12.12
- Huggingface_hub version: 1.18.0
- Safetensors version: 0.8.0
- Accelerate version: 1.15.0.dev0
- Accelerate config:    not found
- DeepSpeed version: not installed
- PyTorch version (accelerator?): 2.12.0+cu130 (CUDA)
- Using distributed or parallel set-up in script?: <fill in>
- Using GPU in script?: <fill in>
- GPU type: NVIDIA A100-SXM4-80GB

### Who can help?

@Cyrilvallez @SunMarc 

### Information

- [ ] The official example scripts
- [x] My own modified scripts

### Tasks

- [x] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

```python3
from transformers import Qwen3VLForConditionalGeneration

model = Qwen3VLForConditionalGeneration.from_pretrained(
    "Qwen/Qwen3-VL-32B-Instruct",
    device_map="auto",
    max_memory={},
    offload_folder="offload_folder",
)
model.save_pretrained("save_path")
```

```
Some parameters are on the meta device because they were offloaded to the disk.
Writing model shards:   0%|                                                                        | 0/2 [00:00<?, ?it/s]
Traceback (most recent call last):
  File "/home/kylesayrs/llm-compressor/disk_save_repro.py", line 12, in <module>
    model.save_pretrained(SAVE_DIR)
  File "/home/kylesayrs/transformers/src/transformers/modeling_utils.py", line 3680, in save_pretrained
    safe_save_file(shard_state_dict, filename, metadata=metadata)
  File "/home/kylesayrs/llm-compressor/env/lib64/python3.12/site-packages/safetensors/torch.py", line 324, in save_file
    _flatten_as_ptr(tensors, keep_references_alive), filename, metadata=metadata
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/kylesayrs/llm-compressor/env/lib64/python3.12/site-packages/safetensors/torch.py", line 582, in _flatten_as_ptr
    arr, tensor_ref = _to_ndarray(v)
                      ^^^^^^^^^^^^^^
  File "/home/kylesayrs/llm-compressor/env/lib64/python3.12/site-packages/safetensors/torch.py", line 479, in _to_ndarray
    tensor = tensor.to("cpu")
             ^^^^^^^^^^^^^^^^
NotImplementedError: Cannot copy out of meta tensor; no data!
```

### Expected behavior

Model should save properly. Issue does not occur when using https://github.com/huggingface/transformers/pull/46902

Comments: