noamaanMulla-03/transformers-issues huggingface dataset:
fix: make num_experts BC fallback not override explicit n_routed_experts
Author: webtecnica
Pull request: yes

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

## Description

Fixes #47355

**Root cause:** In both `GlmMoeDsaConfig.__post_init__` and `DeepseekV32Config.__post_init__`, the backward-compatibility re-route from `num_experts` (legacy key) to `n_routed_experts` was **unconditional** — it could overwrite an explicit `n_routed_experts` value from the same `config.json`.

**Example:** A config with `{"n_routed_experts": 168, "num_experts": 256}` would silently use 256 experts, causing an OOM downstream (vLLM allocates for 256 experts instead of 168).

**Fix:** Only apply the BC fallback when `n_routed_experts` is still at its defining class's default value, which means it was NOT explicitly provided. Since `n_routed_experts` is a dataclass field consumed by `__init__` before `__post_init__` runs, we compare `self.n_routed_experts` against `type(self).n_routed_experts`.

**Files changed:**

| File | Change |
|------|--------|
| `modular_deepseek_v32.py` | Root fix — source that regenerates generated files |
| `configuration_deepseek_v32.py` | Generated copy of the same fix |
| `configuration_glm_moe_dsa.py` | Generated copy (unwrapped from modular) |
| `tests/models/glm_moe_dsa/test_config_glm_moe_dsa.py` | 3 test cases covering the fix + BC preservation |

**Verification (6 test cases, all pass):**

| Scenario | Expected | Result |
|----------|----------|--------|
| Both keys provided | `n_routed_experts=168` wins | ✅ |
| Only legacy `num_experts` | BC fallback applies: 128 | ✅ |
| Only modern `n_routed_experts` | Preserved: 42 | ✅ |
| DeepseekV32Config parent | Same fix: 64 | ✅ |
| Both keys same value (256) | No issue | ✅ |
| Not provided either | Class default (256) | ✅ |

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

run-slow: deepseek_v32, glm_moe_dsa

<!-- 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=47409)
**Latest run:** [29672193811](https://github.com/huggingface/transformers/actions/runs/29672193811)
**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 -->
Wav2Vec2CTCTokenizer in v5 treats the word delimiter as a special token, which leaks into get_special_tokens_mask and convert_ids_to_tokens
Author: ishan-1010
Pull request: no


### System Info

- transformers 5.10.0.dev0 (current main), also reproduces on 5.9.0
- last good: 4.57.6
- Python 3.12, macOS arm64 (CPU only)

### Who can help?

@eustlb

### Reproduction

Runs offline in a few seconds:

```python
import json, tempfile, os
from transformers import Wav2Vec2CTCTokenizer

d = tempfile.mkdtemp()
vocab = {c: i for i, c in enumerate(["<pad>", "
", "
", "<unk>", "|"] + list("abcdefghijklmnopqrstuvwxyz"))}
with open(os.path.join(d, "vocab.json"), "w") as f:
    json.dump(vocab, f)

tok = Wav2Vec2CTCTokenizer(os.path.join(d, "vocab.json"))
ids = tok("hello world")["input_ids"]
print(tok.get_special_tokens_mask(ids, already_has_special_tokens=True))
```

On 4.57.6 this prints all zeros. On v5 the `|` position (id 4) is marked as special:

```
v4.57.6:  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
v5:       [0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0]
```

`tok.all_special_tokens` shows the difference directly: v4 gives `['
', '
', '<unk>', '<pad>']`, v5 gives `['
', '
', '<unk>', '<pad>', '|']`.

### What's going on

In v5 the word delimiter ends up registered as a special token. `_decode` knows about this and exempts it explicitly (tokenization_wav2vec2.py line 430: `... and token != self.word_delimiter_token`), so plain `tokenizer.decode()` still looks fine. But the other special-token-aware APIs got no such exemption:

- `get_special_tokens_mask(..., already_has_special_tokens=True)` marks every `|` as special (output above)
- `convert_ids_to_tokens(ids, skip_special_tokens=True)` drops `|` entirely (line 286 filters on `all_special_ids` with no delimiter exemption), so word boundaries vanish: v4 keeps the delimiter, v5 returns the tokens with all `|` removed

Anything that uses the mask or skip_special_tokens to strip specials (label masking in ASR fine-tuning, WER computation that filters special ids) now eats word boundaries silently. No warning, output just changes.

### Expected behavior

Same as v4: the word delimiter is not a special token for masking/skipping purposes, only for CTC string assembly.

Two ways to fix it, depending on what you prefer: either stop registering the delimiter as special and drop the `_decode` exemption, or keep it special and add the same exemption to `get_special_tokens_mask` and `convert_ids_to_tokens`. Happy to open a PR for either.


Comments:
Hi, I'd like to work on this. I'll submit a PR shortly.

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.
Raise informative error when a converted checkpoint matches none of the loaded class's weights
Author: SelfSL
Pull request: yes

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

Fixes #47405

**Failure mode:** loading a checkpoint whose architecture has registered weight conversions through a non-matching class (e.g. `AutoModelForCausalLM` on a multimodal layout) currently succeeds silently: zero tensors match, the model is fully randomly initialized, and it *generates fluently* -- sending users into weight-level debugging instead of a one-line class fix.

**Change:** in `_finalize_model_loading`, after `_adjust_missing_and_unexpected_keys`, raise a `ValueError` when weight conversions are registered (`load_config.weight_mapping`), there are unexpected checkpoint keys, and >=99% of the model's keys are missing. The error names both counts and points at the Auto-class fix.

Design notes:
- **Outcome-based predicate** (near-total mismatch + conversions present) rather than probing the checkpoint's `model_type` registry -- covers every route into the failure, and cannot fire on any sane partial load.
- **Raise inside the `try`** so the `finally` still emits the full loading report before the exception -- verified: the MISSING/UNEXPECTED table prints, then the error surfaces.
- **No bypass kwarg**: a ~100%-miss load has no legitimate use, and `ignore_mismatched_sizes` has different semantics (shape mismatches). Happy to add an escape hatch if preferred.

Tests: positive (raises with conversions + total mismatch) and negative control (identical mismatch without conversions does not raise) in `tests/utils/test_modeling_utils.py`.

cc @CyrilVallez @zucchini-nlp

---
_Local `make check-repo` note: the `types` check flags a pre-existing `torch.cat(..., axis=-1)` at `modeling_utils.py:985` on clean main; unrelated to this diff. All ruff/style/consistency checks pass._

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

<!-- ci-dashboard-recap:end -->
CompressedTensorsConfig(run_compressed=False) silently random-initializes unmapped fused-MoE expert weights on 5.10.x (works on 5.13.1) — request hard error for unmapped packed tensors
Author: narfian
Pull request: no

**Summary**: Loading a compressed-tensors W4A16 checkpoint of `Qwen/Qwen3.6-35B-A3B` (fused-expert MoE) with `from_pretrained(ckpt, quantization_config=CompressedTensorsConfig(run_compressed=False))` on **transformers 5.10.1** prints:

```
model.language_model.layers.{0...39}.mlp.experts.gate_up_proj_packed | UNEXPECTED
model.language_model.layers.{0...39}.mlp.experts.gate_up_proj        | MISSING
model.language_model.layers.{0...39}.mlp.experts.down_proj           | MISSING
```

i.e. the decompressor does not map the packed fused expert tensors, and those weights are **silently newly-initialized** — the returned "trainable QDQ model" produces garbage logits for every MoE layer while `from_pretrained` "succeeds". This breaks QAT/recovery-training workflows. (Diagnostic: the broken student's logits agree 97% with an independently-loaded copy of itself, but 0% with the uncorrupted teacher.)

**Environment (broken)**: transformers 5.10.1, compressed-tensors 0.17.1.

**Resolution verified**: on transformers **5.13.1** the same flow decompresses correctly (per-expert checkpoint tensors are mapped into the fused module via the conversion-mapping loader; we verified the QDQ values match a manual dequant of the packed weights to 2.4e-4 max abs error).

**Request**: on versions/paths where packed tensors cannot be mapped, please **raise a hard error instead of silently newly-initializing weights**. Silent random init behind a successful `from_pretrained` is the worst failure mode for downstream training pipelines.

Comments:
Opened **Part 1** of this: #47411

Extends the approach from #47408 to also cover quantized checkpoints. After `_finalize_model_loading`, if there's a near-total weight mismatch (>99% missing) WITH either `weight_mapping` or `hf_quantizer` registered, a `ValueError` is raised instead of silently random-initializing.

**Part 2** (the actual fused-MoE decompression fix) still needs to be done — tracking the root cause in the `WeightConverter` / `DecompressExperts` pipeline for fused packed tensors like `gate_up_proj_packed`.

cc @CyrilVallez @zucchini-nlp
fix: raise hard error on total weight mismatch with conversions or quantization
Author: webtecnica
Pull request: yes

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

## Description

Part 1 of #47407

Extends the approach from #47408 to also cover quantized checkpoints. When a checkpoint's tensors match ~nothing while weight conversions or quantization are registered, the model silently random-initializes and generates fluently — a catastrophic failure mode.

**Root cause:** Two separate issues produce the same silent-init pattern:

1. **#47405** — Multimodal checkpoint loaded via `AutoModelForCausalLM` instead of the correct multimodal Auto class. The conversion mapping applies to the wrong class, 0 tensors match.

2. **#47407** — `CompressedTensorsConfig(run_compressed=False)` on a fused-MoE checkpoint where the decompressor cannot map packed expert tensors. UNEXPECTED keys are silently ignored, MISSING keys are randomly initialized.

**Fix:** In `_finalize_model_loading`, after `_adjust_missing_and_unexpected_keys`, raise a `ValueError` when:

- Either `weight_mapping` or `hf_quantizer` is registered, AND
- There are unexpected checkpoint keys, AND
- >=99% of model keys are missing

The error message names the counts and points at the Auto-class fix.

### Key differences from #47408

| Aspect | #47408 (SelfSL) | This PR |
|--------|----------------|---------|
| Check condition | `load_config.weight_mapping` only | `load_config.weight_mapping or load_config.hf_quantizer` |
| Covers quantization | ❌ | ✅ (CompressedTensors, etc.) |
| Covers conversion mapping | ✅ | ✅ |

Both fixes are complementary — this PR is a superset that adds quantizer coverage.

## Test Plan

6 test cases in `tests/utils/test_total_mismatch_hard_error.py`:

| # | Scenario | Expected |
|---|----------|----------|
| 1 | weight_mapping + total mismatch | ValueError ✅ |
| 2 | hf_quantizer + total mismatch | ValueError ✅ |
| 3 | Neither + total mismatch | No error ✅ |
| 4 | Both + total mismatch | ValueError ✅ |
| 5 | 50% mismatch (below threshold) | No error ✅ |
| 6 | No unexpected keys | No error ✅ |

Tests use mocked models (no torch/GPU dependency) for fast execution.

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

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

<!-- ci-dashboard-recap:end -->
fix: Wav2Vec2PhonemeCTCTokenizer.phonemize stale phonemizer_lang
Author: webtecnica
Pull request: yes

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

Fixes #46614

## Root cause

`Wav2Vec2PhonemeCTCTokenizer.phonemize()` re-creates the espeak backend when a different language is requested, but **never updates `self.phonemizer_lang`**. On the next call with the ORIGINAL language, the stale comparison sees `"en-us" != "es"` as True (both differ from the stored `self.phonemizer_lang`), so the backend is NOT re-created and the cached Spanish backend phonemizes the English text.

## Fix

One line: `self.phonemizer_lang = phonemizer_lang` after `self.init_backend(phonemizer_lang)`.

`prepare_for_tokenization()` already sets `self.phonemizer_lang` before `init_backend()` and is not affected.

## Tests

4 new test cases in `tests/models/wav2vec2_phoneme/test_tokenization_wav2vec2_phoneme_fix.py`:

| Test | What it checks |
|------|---------------|
| `test_phonemize_updates_phonemizer_lang` | After switching language, `self.phonemizer_lang` reflects the new value |
| `test_phonemize_same_language_skips_backend_init` | Same language does not re-init backend |
| `test_phonemize_different_language_inits_backend` | Different language does re-init backend |
| `test_phonemize_switch_back_and_forth` | Full regression: en → es → en works correctly |

All tests use mocked backends (no phonemizer/espeak dependency).

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

run-slow: wav2vec2_phoneme

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

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

<!-- ci-dashboard-recap:end -->
fix: raise hard error when compressed-tensors packed weights cannot be mapped
Author: webtecnica
Pull request: yes

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

Closes #47407

When loading a compressed-tensors checkpoint with `run_compressed=False`, packed fused-MoE expert tensors (like `gate_up_proj_packed`) can be UNEXPECTED while their unpacked counterparts (`gate_up_proj`, `down_proj`) are MISSING. On older versions of transformers (e.g., 5.10.x), this causes `from_pretrained` to succeed silently with randomly initialized weights — producing garbage outputs.

This PR adds a check in `_finalize_model_loading` after `_adjust_missing_and_unexpected_keys`: if there are unexpected keys containing `_packed` that have corresponding missing unpacked keys, and weight conversions are registered, we now raise a `ValueError` instead of silently random-initializing the weights.

This prevents the worst failure mode — silent weight corruption behind a "successful" `from_pretrained` — for QAT/recovery-training workflows.

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=47410)
**Latest run:** [29685714575:2](https://github.com/huggingface/transformers/actions/runs/29685714575)
**Result:** `failure` | **Jobs:** 15 | **Tests:** 172,150 | **Failures:** 0 | **Duration:** 14h 54m

<!-- ci-dashboard-recap:end -->
Incompatible with kernels 0.16
Author: jiqing-feng
Pull request: no
Labels: name: bug

### System Info

When I trying to load a model with `use_kernels=True`, the error happens: 
```
Traceback (most recent call last):
  File "/home/sdp/transformers/src/transformers/pipelines/base.py", line 256, in load_model
    model = model_class.from_pretrained(model, **fp32_kwargs)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/sdp/transformers/src/transformers/modeling_utils.py", line 4453, in from_pretrained
    model.set_use_kernels(use_kernels, kernel_config)
  File "/home/sdp/transformers/src/transformers/modeling_utils.py", line 3927, in set_use_kernels
    raise ValueError(
ValueError: Kernels are not available. Please install a compatible version (0.15.2 <= version < 0.16.0), e.g. `pip install kernels==0.15.2`
```

But the released kernels is 0.16.0. Is there any PR to support it?

### Who can help?

@vasqu 

### 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

```python
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("openai/gpt-oss-20b", use_kernels=True)
```

### Expected behavior

Should load correctly without error.

Comments:
Hi @vasqu — I'd like to work on this, could you assign it to me?
I've verified that kernels 0.16.0 only deprecates use_kernel_func_from_hub/FuncRepository without removing them, and all symbols imported by integrations/hub_kernels.py still resolve under 0.16.0. So the fix is bumping KERNELS_MAX_VERSION to "0.17.0" in utils/import_utils.py and the matching kernels>=0.15.2,<0.17 pin in setup.py / dependency_versions_table.py. Happy to also migrate to the new use_kernel_forward_from_hub + use_kernelized_func pattern in a follow-up to silence the deprecation warnings. Will open a PR shortly.

Hey @birugit, I already have a PR over here https://github.com/huggingface/transformers/pull/46883 - it just depends on one other open PR then I will revisit and merge that one 🤗 

Get issue comments
fix: add missing get-pr-number dependency in pr_build_doc_with_comment.yml (#47293)
Author: webtecnica
Pull request: yes

## Summary

Fixes #47293 — the `pr_build_doc_with_comment.yml` workflow has been silently failing at startup since April 2026 (3,086 startup failures, 0 notifications) because the `verity_pr_commit` job references `needs.get-pr-number.outputs.PR_NUMBER` in its `if:` condition but `get-pr-number` was not listed in its `needs:` dependency list.

## Root Cause

The `verity_pr_commit` job:

```yaml
  verity_pr_commit:
    if: ${{ needs.get-pr-number.outputs.PR_NUMBER != ''}}
    runs-on: ubuntu-22.04
    needs: get-pr-info
```

GitHub Actions rejects a workflow at parse time when a job's `if:` condition references a job that is not in its own `needs:` list. Since `get-pr-number` was missing from `needs:`, the entire workflow was rejected before any job could run — producing no failing check and no notification.

## Change

Added `get-pr-number` to the `needs:` list:

```diff
-    needs: get-pr-info
+    needs: [get-pr-number, get-pr-info]
```

## Verification

- The fix is a one-line change that aligns the `needs:` list with what the `if:` condition already references.
- All other jobs in the workflow (`get-pr-info`, `create_run`, `build-doc`, `update_run_status`) already correctly list both `get-pr-number` and `get-pr-info` in their `needs:`.

/cc @kobihikri

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

A maintainer can review and manually approve CI if a finding is a false positive.
fix: serialize ContinuousBatchingConfig properly instead of null (#47039)
Author: webtecnica
Pull request: yes

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

# What does this PR do?

Fixes #47039 — `ContinuousBatchingConfig` was serializing as `null` in `GenerationConfig.to_json_string()` because it lacked a `to_dict()` method and its nested `CompileConfig` fields weren't being rehydrated after JSON round-trip.

## Changes

### `src/transformers/generation/configuration_utils.py`

1. **`ContinuousBatchingConfig.to_dict()`** — New method that serializes the instance to a dict, properly calling `to_dict()` on nested `CompileConfig` fields (`varlen_compile_config`, `decode_compile_config`).

2. **`ContinuousBatchingConfig.__post_init__()`** — Added rehydration of nested `CompileConfig` from dicts (handles the deserialization path after JSON round-trip).

3. **`GenerationConfig.__init__()`** — Added rehydration of `ContinuousBatchingConfig` from dict when a plain dict is passed (e.g., from `from_pretrained` after JSON deserialization).

### `tests/generation/test_configuration_utils.py`

- Added `test_serialize_generation_continuous_batching_config` — Verifies:
  - Round-trip save/load preserves `ContinuousBatchingConfig` type and values
  - Nested `CompileConfig` fields are properly rehydrated
  - JSON output does not contain `continuous_batching_config: null`
  - `_compile_all_devices` is not leaked through `CompileConfig` serialization

## Who can review?

@Rocketknight1 @remi-or

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

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