noamaanMulla-03/transformers-issues huggingface dataset:
fix: propagate dtype to text sub-config for composite models in Auto classes
Author: Achyuthan-S
Pull request: yes
Labels: name: Code agent slop

Fixes #46459

**Problem**
dtype passed to AutoModelForCausalLM.from_pretrained is silently ignored for composite (multimodal) checkpoints like Qwen3.5. AutoConfig.from_pretrained absorbs it into the top-level composite config, which is then swapped to the text sub-config via get_text_config() — dropping the user's value. The model falls back to the checkpoint default (bfloat16) with no warning.

**Fix**
Propagate parent_config.dtype to the extracted text sub-config at both get_text_config() call sites in auto_factory.py, mirroring the existing quantization_config propagation from #45494.

**Coordination**
Coordinated on issue #46459 before opening this PR. Issue author (@qflen) acknowledged with approval.

**Duplicate check**
gh pr list --repo huggingface/transformers --state open --search "46459 in:body" returned no results. No overlapping open PRs exist.

**Tests run**
pytest tests/models/qwen3_5/test_modeling_qwen3_5.py::Qwen3_5ModelTest::test_automodelforcausallm_propagates_dtype
PASSED

AutoModelForCausalLM.from_pretrained("Qwen/Qwen3.5-0.8B", dtype=torch.float32)
Output: torch.float32 

**AI assistance disclosure**
AI assistance (Claude) was used for codebase fix verification. All changed lines were reviewed and understood by personally , and the fix was validated locally end-to-end.

The tests_generate failure is a pre-existing flaky test — Kosmos2_5ModelTest::test_generate_with_cache_matches_no_cache — marked FLAKY by CircleCI. It tests cache consistency in Kosmos2.5 generation and has no relation to this change.

@Cyrilvallez @zucchini-nlp

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

run-slow: auto, qwen3_5
docs: wrap sam3-litetext inference example in torch.inference_mode()
Author: kpal002
Pull request: yes
Labels: name: Code agent slop

## Summary

Fixes #46369 — GPU memory overflow when running repeated inference with the SAM3-LiteText model.

- Add `import torch` to the usage example in `docs/source/en/model_doc/sam3_lite_text.md`
- Wrap the forward pass with `with torch.inference_mode():` to prevent autograd from retaining intermediate tensors across calls

Without `torch.inference_mode()`, PyTorch builds a computation graph and holds onto intermediate activations, causing GPU memory to grow with each inference call until it overflows. This is a pure docs fix — no model behaviour changes.

## Test plan

- [ ] Verify the updated code snippet runs without OOM on repeated calls
- [ ] Confirm the rendered docs look correct

Comments:
Support loading original InternVL2 checkpoints natively
Author: malakazlan
Pull request: yes

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

# What does this PR do?

The original `OpenGVLab/InternVL2-*` checkpoints ship the bespoke `internvl_chat`
remote-code layout. Under Transformers v5 (meta-device init), that custom code
calls `.item()` during construction and crashes, so the checkpoints can no longer
be loaded via `AutoModel.from_pretrained(..., trust_remote_code=True)`. This is the
blocker tracked in vllm-project/vllm#38425.

This PR makes the original checkpoints load into the **native**
`InternVLForConditionalGeneration`, without remote code:

- **Config alias** — register the `internvl_chat` `model_type` as an alias of the
  native `InternVLConfig` (mirrors the existing `gpt-sw3` → `GPT2Config` alias), so
  `AutoConfig`/`AutoModel` resolve the local implementation when `trust_remote_code`
  is not passed (per @hmellor's guidance in the linked issue).
- **Config normalization** — map the original `internvl_chat` config
  (`llm_config` / `intern_vit_6b` `vision_config` / `select_layer`) onto
  `InternVLConfig` in `from_dict`.
- **Load-time weight conversion** — rename the original weight layout onto the
  native names and split the fused vision `attn.qkv` into `q/k/v` via `Chunk`,
  reusing the mapping already established in `convert_internvl_weights_to_hf.py`.

## Test plan

Built Transformers from source (v5) and verified on `OpenGVLab/InternVL2-1B`:

- `AutoConfig.from_pretrained(..., trust_remote_code=False)` returns a native
  `InternVLConfig` (Qwen2 text + InternVL vision sub-configs).
- `from_pretrained` loads with **no missing / unexpected / mismatched** weights.
- Each converted tensor (incl. the split `q/k/v`) is **bit-exact** vs. the original.

Added `tests/models/internvl/test_modeling_internvl.py::InternVLOriginalCheckpointTest`
(passes, CPU-only).

## Notes

- InternVL2-2B (InternLM2 backbone, interleaved `wqkv` split) is a planned follow-up.
- Loading emits the generic “model of type `internvl_chat` … `internvl`” info
  warning; happy to silence it for this alias if preferred.
- AI assistance was used; I have reviewed every line and can defend the change.

cc @hmellor

## Before submitting
- [x] Read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md).
- [x] Added tests.

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

run-slow: auto, internvl

<!-- 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=47047)
**Latest run:** [28684427653:2](https://github.com/huggingface/transformers/actions/runs/28684427653)
**Result:** `failure` | **Jobs:** 15 | **Tests:** 170,843 | **Failures:** 2 | **Duration:** 24h 55m

<!-- ci-dashboard-recap:end -->
Fix AltCLIP text embedding resize test
Author: IMvision12
Pull request: yes

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

**Title**  
Fix AltCLIP text embedding resize test

**Description**  
This PR re-enables the AltCLIP text model resize-token-embeddings test and fixes the `_input_embed_layer` name on `AltCLIPTextModel` to match the actual nested `word_embeddings` module.

The resize path now correctly points tooling and common model utilities at the text embeddings, and the previously skipped common resize test is restored.

Verification:
- Ran a local reproduction of the common resize-token-embeddings flow.
- Ran `py_compile` on the touched AltCLIP files.
- Could not run targeted pytest locally because `parameterized` is missing in the environment.


@zucchini-nlp @ArthurZucker

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

run-slow: altclip

<!-- 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=47079)
**Latest run:** [28726122128:2](https://github.com/huggingface/transformers/actions/runs/28777620544)
**Result:** `success` | **Jobs:** 4 | **Tests:** 580 | **Failures:** 0 | **Duration:** 2m 57s

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

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_47079). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
_sanitize_module_name doesnt handle path traversal chars
Author: olliezyuhscripta
Pull request: no

﻿_sanitize_module_name in dynamic_module_utils.py only replaces `.` and `-` before using the result in file paths

```python
new_name = name.replace(".", "_dot_").replace("-", "_hyphen_")
```

but repo names from the hub could potentially contain other characters that would break or escape the intended path. like if a malicious repo had `../` in its name youd get path traversal through the cache dir. the function warns about non-identifier names but doesnt raise or block them

probably not exploitable on the hub since repo names have restrictions, but someone running against a local directory with a weird name could hit it

not urgent, just noticed


Comments:
Wouldn't `../` be replaced with `_dot__dot_`?

Hi! I'd like to work on this. My proposed fix is to use os.path.basename() combined with a regex that strips all non-alphanumeric/underscore characters (or raises a ValueError for invalid names) in _sanitize_module_name. Would that approach work, or do you prefer only stripping the dangerous chars and warning? Happy to submit a PR once I get a thumbs up on the approach.





> Wouldn't `../` be replaced with `_dot__dot_`?

../  would become `_dot__dot_/` i guess

Happy to take this if it's still open, could a maintainer give a quick go-ahead before I open a PR?

One thing I noticed while digging in: the `..` case is actually already handled, since `name.replace(".", "_dot_")` turns `..` into `_dot__dot_` before it's ever used in a path. What's still open is the path separators themselves surviving sanitization:
- in the remote path, the name is split on `/` and the segments are rejoined with `os.path.sep`, so a `\` inside a segment can still inject an extra path level on Windows
- in the local path, `os.path.basename(os.path.normpath(...))` strips traversal on the native OS, but a name containing the *other* platform's separator (e.g. a `\` in a directory name on Linux) slips through

So it's really cross-OS separator hardening rather than a `..` traversal hole,low severity, which lines up with your note that it's probably not exploitable through the hub.

The fix I have in mind extends `_sanitize_module_name` to also replace `/` and `\` (e.g. with `_slash_` / `_backslash_`), in the same explicit-token style as the existing `_dot_`/`_hyphen_` so it doesn't introduce `_` collisions. I'd add a small unit test as well, since the function has no coverage right now.

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.
Make doc builds faster
Author: mishig25
Pull request: yes

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

Companion to the doc-builder tracker: huggingface/doc-builder#802

🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

A maintainer can review and manually approve CI if a finding is a false positive.

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

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

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_47099). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Qwen3.5 crash with `cache_implementation="static"` — `KeyError: 'linear_attention'`
Author: dacorvo
Pull request: no

### System Info

transformers **5.10.1** (latest release)

`generate()` pre-builds attention masks for compilable caches via `create_masks_for_generate`, which maps each `config.layer_types` entry through `LAYER_PATTERN_TO_MASK_FUNCTION_MAPPING`.

Hybrid linear-attention models (Qwen3.5, Qwen3-Next, MiniMax, …) have `linear_attention` layer types, which have **no entry** in `LAYER_PATTERN_TO_MASK_FUNCTION_MAPPING` (they build their own per-layer masks in the forward — `create_causal_mask` for attention layers, a separate 2D/None mask for linear ones). So requesting a static/compilable cache makes `generate()` fail with a cryptic `KeyError: 'linear_attention'`, before reaching the model.

This affects any compilable cache (`cache_implementation="static"`, or a pre-built `StaticCache` passed via `past_key_values=`).

Note: `_can_compile_fullgraph = False` on these models does **not** guard this at runtime — it is read only by test skip-guards (`if not model_class._can_compile_fullgraph: skipTest(...)`), never by `_valid_auto_compile_criteria`. So the path is user-reachable and the breakage is untested.

### Reproduction

Self-contained (no checkpoint download), small hybrid Qwen3.5:

```python
import torch
from transformers import Qwen3_5ForCausalLM
from transformers.models.qwen3_5.configuration_qwen3_5 import Qwen3_5TextConfig

cfg = Qwen3_5TextConfig(
    vocab_size=2048, hidden_size=256, intermediate_size=256, num_hidden_layers=8,
    num_attention_heads=4, num_key_value_heads=2, head_dim=64,
    linear_conv_kernel_dim=4, linear_key_head_dim=32, linear_value_head_dim=32,
    linear_num_key_heads=2, linear_num_value_heads=4, pad_token_id=0, bos_token_id=1, eos_token_id=2,
)
model = Qwen3_5ForCausalLM(cfg).to("cuda").eval()
ids = torch.randint(10, 2000, (1, 16), device="cuda")
model.generate(ids, max_new_tokens=4, cache_implementation="static", disable_compile=True)
# KeyError: 'linear_attention'  (in create_masks_for_generate)
```

A dynamic cache (the default) works fine; only the static/compilable path fails.

### Proposed fix

Make `create_masks_for_generate` **defer to the model** — return the raw attention mask so the forward builds its own per-layer masks — whenever a layer type has no registered mask function, instead of raising.

### Expected behavior

`generate(cache_implementation="static")` on a hybrid linear-attention model should work (defer mask building to the model), not raise a cryptic `KeyError`.

### Who can help?

@ArthurZucker @Cyrilvallez

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.

Fixed as part of #46446
Static cache `early_initialization` corrupts linear-attention layers (wrong shapes → `RuntimeError`)
Author: dacorvo
Pull request: no

### System Info

transformers **5.10.1** (latest release)

`Cache.early_initialization(batch_size, num_heads, head_dim, dtype, device)` pre-allocates all cache layers ahead of time, assuming there is a helper registered to precompute the cache shape available for the layer type.

But there are no registered helpers for linear-attention layers (`mamba`/`conv`/`linear_attention`, `LinearAttentionCacheLayerMixin`) because they manage their own statically-shaped conv/recurrent states, whose shapes (conv kernel, SSM state size, …) aren't derivable from `(num_heads, head_dim)`. Feeding them a `(batch, num_heads, 0, head_dim)` tensor silently allocates a wrongly-shaped `conv_states` (note the spurious 0-length axis) and flags them initialized; the first real `update_conv_state(...)` then does `conv_states.copy_(...)` with mismatched shapes and raises `RuntimeError`.

Relatedly, `Cache.is_initialized` does `all(layer.is_initialized for layer in self.layers)`, which `AttributeError`s on a hybrid cache because linear-attention layers have no `is_initialized` attribute.

### Reproduction

```python
import torch
from transformers import LlamaConfig, StaticCache

cfg = LlamaConfig(num_hidden_layers=2, num_attention_heads=4, num_key_value_heads=2, hidden_size=32)
cfg.layer_types = ["full_attention", "linear_attention"]
cache = StaticCache(config=cfg, max_cache_len=8)

cache.early_initialization(batch_size=1, num_heads=2, head_dim=8, dtype=torch.float32, device="cpu")
print(cache.layers[1].conv_states.shape)          # torch.Size([1, 2, 0, 8])  <- wrong (0-length axis)
cache.layers[1].update_conv_state(torch.zeros((1, 8, 4)))
# RuntimeError: The size of tensor a (8) must match the size of tensor b (4) at non-singleton dimension 3
```

### Proposed fix

In `early_initialization`, read the flag defensively (`getattr(layer, "is_initialized", None)`) and skip layers where it is `None` (layers that don't use the key/value lazy-init, e.g. linear attention) or already `True` (idempotent on a reused cache). Make `Cache.is_initialized` ignore those layers so a hybrid cache reflects its attention layers. (Fix available; comes with a model-free regression test.)

### Expected behavior

`early_initialization` should initialize attention layers and leave linear-attention layers to lazily initialize from their real states on first update; `cache.is_initialized` should not crash on a hybrid cache.

### Who can help?

@ArthurZucker @Cyrilvallez @vasqu 

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.

Fixed as part of #46446
fix: remove upper bound on tokenizers version constraint
Author: ranjithchinnanan
Pull request: yes

Removes the upper bound `<=0.23.0` on the `tokenizers` dependency. This was blocking users from installing tokenizers 0.23.1+ which includes performance improvements. The lower bound `>=0.22.0` is kept.                                                            
                                                                                                                                     
  Fixes #45736 

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

run-slow: clip, herbert, layoutlmv3, roberta

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=45784&sha=e0e58b

Can you take a look at the failing CI checks?

Version bumps like these will generally be handled internally

see #46381

> Version bumps like these will generally be handled internally

Is there some issue where we can follow the progress?
[Proposal] HeartFlow - Cognitive Engine for HuggingFace Transformers
Author: yun520-1
Pull request: no
Labels: name: Code agent slop

## Proposal: HeartFlow × HuggingFace Transformers

### What is HeartFlow?

HeartFlow is an **AI cognitive engine** (68 modules) that adds judgment to any HuggingFace model:

```
├── Three-Layer Memory    # Context persistence
├── Decision Routing      # 34 rules → 8 strategies
├── U/D/A/H Field        # Cognitive health monitoring
├── Self-Healing RL      # Q-learning improvement
└── Shield Module        # Security guardrails
```

### U/D/A/H Cognitive Framework

Real-time cognitive health quantification:

```
H = 0.4·U + 0.3·D - 0.3·A

U (Unity): Identity consistency
D (Development): Logical progression
A (Adversity): Contradiction detection
H (Harmony): Quality score
```

### Benchmarks

| Task | Baseline | +HeartFlow |
|------|----------|------------|
| Logical Reasoning | 67% | **100%** |
| Decision Making | 50% | **100%** |

### Transformers Integration

1. **Model-agnostic**: Works with any HF model (Llama, Mistral, Gemma...)
2. **Pipeline enhancement**: Add cognitive layer to existing pipelines
3. **Benchmarking**: U/D/A/H as standard LLM cognitive metric
4. **Safety**: Shield module for prompt injection prevention

### Links

- GitHub: https://github.com/yun520-1/mark-heartflow-skill

---
*HeartFlow v5.5.1 — Transformers with Judgment*

Comments:
Guard DETR and Grounding DINO Hungarian matchers against infinite cost matrices
Author: MutugiD
Pull request: yes
Labels: name: Code agent slop

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

# What does this PR do?

Follow-up to #47000 / #47016. The RT-DETR fix in #47016 guards `RTDetrHungarianMatcher` against non-finite cost matrices, but the same unguarded `scipy.optimize.linear_sum_assignment(cost_matrix)` pattern also exists in two sibling matchers that #47016 does not touch:

- `HungarianMatcher` in `src/transformers/loss/loss_for_object_detection.py` (used by the DETR / Deformable DETR family)
- `GroundingDinoHungarianMatcher` in `src/transformers/loss/loss_grounding_dino.py`

Under AMP/fp16, the focal-style classification cost can overflow to `inf`/`NaN`; `linear_sum_assignment` then raises `ValueError: cost matrix is infeasible`. This PR replaces non-finite costs with `torch.finfo(cost_matrix.dtype).max` before matching, following @guarin's recommendation in #47000:

```python
max_value = torch.finfo(cost_matrix.dtype).max
cost_matrix = torch.nan_to_num(cost_matrix, nan=max_value, posinf=max_value, neginf=max_value)
```

## Tests

Adds a CPU-only regression test for each matcher:

- `tests/models/detr/test_modeling_detr.py::HungarianMatcherInfeasibleCostTest`
- `tests/models/grounding_dino/test_modeling_grounding_dino.py::GroundingDinoHungarianMatcherInfeasibleCostTest`

Each feeds a non-finite cost (a `NaN` logit and an `inf` box coordinate) through the matcher and asserts it no longer raises and returns correctly-sized assignments. Both tests fail on `main` (with the `ValueError`) and pass with the guard.

```
pytest tests/models/detr/test_modeling_detr.py::HungarianMatcherInfeasibleCostTest \
       tests/models/grounding_dino/test_modeling_grounding_dino.py::GroundingDinoHungarianMatcherInfeasibleCostTest
```

The same pattern is also present in `loss_deformable_detr.py` and `loss_lw_detr.py`. I scoped this PR to the two files flagged in #47000, but I'm happy to extend the guard to those as well if you'd prefer a single sweep.

## Before submitting

- [x] This PR fixes a bug discussed in an issue: #47000
- [x] Did you make sure to update the documentation with your changes? (N/A — no user-facing API change)
- [x] Did you write any new necessary tests?

## Who can review?

@guarin @yonigozlan

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

run-slow: detr, grounding_dino

<!-- 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=47048)
**Latest run:** [28688965854:2](https://github.com/huggingface/transformers/actions/runs/28688965854)
**Result:** `success` | **Jobs:** 15 | **Tests:** 171,199 | **Failures:** 0 | **Duration:** 26h 56m

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