noamaanMulla-03/transformers-issues huggingface dataset:
Fix typo in docstring for `Sam3TrackerConfig`
Author: alvarobartt
Pull request: yes

# What does this PR do?

This PR fixes a typo in `Sam3Tracker` docstring in `Sam3Trackerconfig`, which is fixed as `Sam3TrackerConfig` (casing in the "c").

## Before submitting

- [x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request), Pull Request section?
- [ ] Was this discussed/approved via a GitHub issue or the [forum](https://discuss.huggingface.co/)? Please add a link to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?

## Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

@yonigozlan 

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

@alvarobartt can you make the update in the `modular` file for `sam3` and then run `make fix-repo` to sort out the consistency checks?

> @alvarobartt can you make the update in the `modular` file for `sam3` and then run `make fix-repo` to sort out the consistency checks?

Hey @Rocketknight1, so apparently the typo is not in the modular file, but rather also on the `Sam2Config` inherited class, which seems not generated from the modular file for SAM2, right? Maybe I'm missing something not sure, I've updated the typo in the `Sam2Config` docstring too though!

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

run-slow: edgetam, sam2, sam3_tracker

Wow, yes, this was a capitalization issue that propagated across two totally different class names via modular updates. I've never seen that before, but good job figuring it out!
Fix failing `ChameleonIntegrationTests`
Author: Sai-Suraj-27
Pull request: yes

# What does this PR do?

Fixes these failing [ChameleonIntegrationTests](https://github.com/huggingface/transformers/actions/runs/21199210283/job/60982512511#step:14:5322)

<img width="2294" height="322" alt="Screenshot from 2026-01-22 07-24-39" src="https://github.com/user-attachments/assets/b3650c09-6a9c-4280-adbd-2258087180d5" />




## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?
@Rocketknight1 @vasqu

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

run-slow: chameleon

run-slow: chameleon

This comment contains `run-slow`, running the specified jobs: 

models: ["models/chameleon"]
quantizations: []

## CI Results
[Workflow Run ⚙️](https://github.com/huggingface/transformers/actions/runs/21251967920)

✅ No failing test specific to this PR 🎉 !
Fix failing `recurrent_gemma` tests
Author: Sai-Suraj-27
Pull request: yes

# What does this PR do?

Fixes these failing [recurrent_gemma](https://github.com/huggingface/transformers/actions/runs/21199210283/job/60982514314#step:14:6060) tests.


<img width="2311" height="472" alt="image" src="https://github.com/user-attachments/assets/75b3122d-714a-4e95-8a99-de3886358ceb" />





## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?
@Rocketknight1 @vasqu, @Cyrilvallez (https://github.com/huggingface/transformers/pull/43255)

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

run-slow: recurrent_gemma

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43405). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Qwen3-VL checkpoints don't have pad_token
Author: Rocketknight1
Pull request: no

`AutoModelForImageTextToText.from_pretrained("Qwen/Qwen3-VL-2B-Instruct")` fails for me because of the line `self.padding_idx = config.pad_token_id`, but the checkpoints do not have `pad_token_id` set and the configs don't have a default value for it. Should we update the checkpoints or change that line?

cc @zucchini-nlp

Comments:
@Rocketknight1 If thats ok,  I’m planning to take a stab at this issue and put together a PR.
This looks closely related to #43334 . I’m still building familiarity with these models, so I’ll keep the fix focused and add a regression test if  needed.
I might be a little slower compared to @zucchini-nlp but I can give it a try, please let me know.

@Rocketknight1 @zucchini-nlp 
I went thru the existing configuration and it looked pretty straightforward to me (I could be wrong). if we just add the missing config (pad_token_id) and here is my thought process. 

pad_token_id is a standard PreTrainedConfig field used across the HF stack (tokenizers, data collators, generation utilities, and training helpers). Removing padding_idx would only paper over the missing config field and could lead to inconsistent behavior elsewhere. 

so I added pad_token_id to Qwen3VLTextConfig (using modular_qwen3_vl.py) with a default of None and forwarded it through PreTrainedConfig. This makes the config schema match what the model expects without inventing padding semantics for checkpoints that do not define a pad token. When unset, the embedding is created with padding_idx=None, which preserves the original behavior. I also added a regression test to ensure Qwen3VLTextModel can be instantiated when pad_token_id is not provided, which mirrors the real from_pretrained failure path and should prevent this from regressing.

requesting you both to give the PR a review and please let me know if my understanding is correct.

The issue is in out config defaults. I recently merged a PR moving all non-common config attributes from `PreTrainedConfig` to the respective `ModelConfig` classes. Sadly qwen3-vl never had an integration test so we missed it

@vaibhav-research reviewed your PR!

thanks @zucchini-nlp , will update the PR based on your feedback.
Fix float16 inference for Sam2 Video / Sam3 Video / Sam3 Video Tracker + add tests
Author: yonigozlan
Pull request: yes

Issue originally raised in https://github.com/huggingface/transformers/pull/43268, but provided fix changes inference values for other dtypes. This keeps memory saved as bf16 and only convert concatenated memory to `inference_session` dtype.

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

run-slow: edgetam_video, sam2_video, sam3_tracker_video, sam3_video

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

Closing as changes pushed directly in the original PR
tokenizer.decode producing bad results in some cases from 5.0.0rc1 to 5.0.0rc2
Author: awni
Pull request: no
Labels: name: bug

### Repro

Try running with 5.0.0rc1 vs 5.0.0rc2. The former reproduces the text. The latter gives a bad result: `Th is <unk> is <unk> a <unk> te st`.

```python
from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("IQuestLab/IQuest-Coder-V1-40B-Loop-Instruct", trust_remote_code=True)

print(tokenizer.decode(tokenizer.encode("This is a test")))
```

### Who can help?

@ArthurZucker 


### Expected behavior

Should both result in `This is a test`

Comments:
I traced this down - PR #42894 added an early-exit to `TokenizersBackend` when there's a tokenizer class mismatch, but this check happens before looking at `auto_map`. So for models like yours with a custom `model_type` that isn't in `TOKENIZER_MAPPING_NAMES`, it was falling back to `TokenizersBackend` instead of loading your custom tokenizer via `auto_map`.

Opened #43219 with a fix that moves the `auto_map` check before the early-exit, so custom tokenizers with `trust_remote_code=True` work correctly again.
Fix tokenizer auto_map being ignored for custom models
Author: Anri-Lombard
Pull request: yes

Fixes #43202

PR #42894 introduced an early-exit to `TokenizersBackend` when `tokenizer_class` doesn't match the registered tokenizer for a `model_type`. However, this check was placed before the `auto_map` extraction, causing custom tokenizers (with `trust_remote_code=True`) to be ignored.

Reproduction:
```python
from transformers import AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained("IQuestLab/IQuest-Coder-V1-40B-Loop-Instruct", trust_remote_code=True)
print(tokenizer.decode(tokenizer.encode("This is a test")))
# Expected: "This is a test"
# Actual (bug): "Th is <unk> is <unk> a <unk> te st"
```

For models with unregistered `model_type` (like `iquestloopcoder`), the condition `TOKENIZER_MAPPING_NAMES.get(model_type, "") != tokenizer_config_class` is always True, causing early-exit to `TokenizersBackend` without checking if `auto_map` exists.

This fix moves the `auto_map` extraction before the early-exit check and adds `tokenizer_auto_map is None` to the condition.

Added regression test `test_custom_tokenizer_with_mismatched_tokenizer_class`.

Comments:
cc @itazap @ArthurZucker 

@Anri-Lombard @ArthurZucker thanks for the fix here. We are depending on it in mlx-lm and looking forward to the next RC.


Can you fix the quality checks please?! 🤗 

@bot /style

Style fix is beginning .... [View the workflow run here](https://github.com/huggingface/transformers/actions/runs/21257673443).

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

run-slow: auto

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

I was so free to make the style check myself to merge, thanks for contributing :heart:
fix: _get_num_multimodal_tokens video branch (#43329)
Author: floor-licker
Pull request: yes
Labels: name: Code agent slop

# What does this PR do?

Fixes #43329

 ### Summary
  `_get_num_multimodal_tokens(video_sizes=...)` crashed in multiple multimodal processors because the
  video branch called `self.video_processor.get_number_of_video_patches(...)` (not implemented on several video
  processors), and used `merge_size` without initializing it (it was only set in the image branch).

  This meant CI never exercised the video route (tests only covered `image_sizes`).

  ### Changes

  - Initialize merge_size in the video_sizes branch (from videos_kwargs.get("merge_size") fallback to
    self.video_processor.merge_size).
  - Add get_number_of_video_patches() to the relevant *VideoProcessor implementations (either as an
    alias to the existing helper or as a small utility consistent with preprocessing).
  - Add unit coverage that calls _get_num_multimodal_tokens(video_sizes=[(8, 224, 224)]) so the video
    branch is exercised in CI.

  ### Affected processors

  - Ernie4_5_VL_MoeProcessor
  - Glm4vProcessor
  - Glm46VProcessor
  - Qwen2VLProcessor
  - Qwen2_5_VLProcessor
  - Qwen3VLProcessor
  - VideoLlama3Processor

  ### Relevant Tests

  python -m pytest -q \
    tests/models/qwen2_vl/test_processing_qwen2_vl.py::Qwen2VLProcessorTest::test_get_num_vision_tokens
  \
    tests/models/qwen2_5_vl/
  test_processing_qwen2_5_vl.py::Qwen2_5_VLProcessorTest::test_get_num_vision_tokens \
    tests/models/qwen3_vl/test_processing_qwen3_vl.py::Qwen3VLProcessorTest::test_get_num_vision_tokens
  \
    tests/models/video_llama_3/
  test_processing_video_llama_3.py::VideoLlama3ProcessorTest::test_get_num_vision_tokens \
    tests/models/ernie4_5_vl_moe/
  test_processing_ernie4_5_vl_moe.py::Ernie4_5_VL_MoeProcessorTest::test_get_num_vision_tokens \
    tests/models/glm4v/test_processor_glm4v.py::Glm4vProcessorTest::test_get_num_vision_tokens_video \
    tests/models/glm46v/test_processor_glm46v.py::Glm46VProcessorTest::test_get_num_vision_tokens_video


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

run-slow: ernie4_5_vl_moe, glm46v, glm4v, qwen2_5_vl, qwen2_vl, qwen3_vl, video_llama_3

cc @zucchini-nlp, feels like a code agent PR but feel free to merge it if it works

cc @Rocketknight1 @zucchini-nlp i created this issue initially asking to also do the PR, but this came in automatically before i got an answer. no worries, if it works it works.

suggestions: 
I would suggest we also include a batch to test the function _get_num_multimodal_tokens() -like we do in the image branch-, instead of a single item, and also improve a bit the depth of these tests (eg. `do_resize` ).
LiquidAI models: Prevent leaking image information across batched queries
Author: ChristopherBrix
Pull request: yes

# What does this PR do?

Currently, there's a bug in the preprocessing logic of images for LiquidAI models: If there are multiple queries batched together, fragments of the image in one query may be swapped with fragments of the image in another query. This degrades the output quality and could leak information from one user to another.

To replicate this issue, run the following code:
```
from transformers import AutoModelForImageTextToText, AutoProcessor
from transformers.image_utils import load_image
from PIL import Image

model_id = "LiquidAI/LFM2-VL-450M"
model = AutoModelForImageTextToText.from_pretrained(
    model_id, device_map="auto", dtype="float64"
)
processor = AutoProcessor.from_pretrained(model_id)

PROMPT = "What colors are in this image? How much of each color is there?"
COLORS = [
    (255, 0, 0),    # Red
    (0, 255, 0),    # Green
]
IMAGE_SIZE = (1024, 1024)

conversations = [
    [
        {
            "role": "user",
            "content": [
                {"type": "image", "image": Image.new("RGB", IMAGE_SIZE, color=color)},
                {"type": "text", "text": PROMPT},
            ]
        },
    ] for color in COLORS
]

inputs = processor.apply_chat_template(
    conversations,
    add_generation_prompt=True,
    return_tensors="pt",
    return_dict=True,
    tokenize=True,
).to(model.device)
outputs = model.generate(**inputs, max_new_tokens=640)
response = processor.batch_decode(outputs, skip_special_tokens=True)

for color, r in zip(COLORS, response):
    print("Response for color", color)
    print(r)
    print()
```

Run this once with both colors, and once with only red and green, respectively.

Expected behavior: If both queries are batched, the output is the same as what you'd get in individual queries (modulo some variability).
Actual behavior: For the individual queries, the response correctly states that the image is green/red (the model may hallucinate that there's also some black/white). For the batched inference run, the model reports "Mostly red + some green" and "Mostly green + some red", clearly demonstrating the leak of information.

This is fixed by applying the change from this PR.


## Before submitting
- [X] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?

## Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

@zucchini-nlp, @ankke, @yonigozlan  

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

run-slow: lfm2_vl

Thank you! We have a PR open here: #43379

Let's close it in favor of the PR from LiquidAI team as the other one is more complete. Thanks @ChristopherBrix !
🚨Fix default interpolation for PVT to match original implementation (Bicubic)
Author: Arpit2744
Pull request: yes

# What does this PR do?

This PR updates the default interpolation method for `PvtImageProcessor` (both standard and fast versions) from `BILINEAR` to `BICUBIC`.

# Motivation

The original PVT implementation follows the DeiT training recipe, which relies on Bicubic interpolation.
Additionally, the `timm` library (the standard reference for this model) uses `interpolation='bicubic'` for all PVT variants.
Vision Transformers generally require Bicubic interpolation to preserve high-frequency details during patch embedding.

# Checklist
- [x] I have updated the interpolation to `PILImageResampling.BICUBIC`.

Comments:
Ready for review! I have updated the interpolation to BICUBIC to match the original implementation. I also removed the 'Copied from' tag since the implementation now differs from VIT All 18 CI tests are passing.

cc @molbap @yonigozlan 

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

run-slow: pvt

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43017). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix Mamba2ForCausalLM weight tying
Author: Anri-Lombard
Pull request: yes

## What does this PR do?

Fixes #43206

Adds the `_tied_weights_keys` mapping to `Mamba2ForCausalLM` to enable proper weight tying when `tie_word_embeddings=True`.

## The Bug

When `tie_word_embeddings=True`, the embedding weights should be shared with the `lm_head`. However, `Mamba2ForCausalLM` had:
```python
_tied_weights_keys = {}  # Empty - weight tying never happens
```

This caused:
- Weights not actually tied (different tensors)
- `resize_token_embeddings()` not resizing `lm_head` properly

## The Fix

```python
_tied_weights_keys = {"lm_head.weight": "backbone.embeddings.weight"}
```

This is the standard pattern used by `MambaForCausalLM` (v1), GPT2, LLaMA, and other models.

## Verification

```python
from transformers import Mamba2ForCausalLM, Mamba2Config

config = Mamba2Config(vocab_size=1000, tie_word_embeddings=True)
model = Mamba2ForCausalLM(config)

# Weights are now properly tied
assert model.lm_head.weight.data_ptr() == model.backbone.embeddings.weight.data_ptr()

# Resize works correctly
model.resize_token_embeddings(1100)
assert model.lm_head.weight.shape[0] == 1100
```

Comments:
Thanks! Enabled `tie_word_embeddings=True` in the ModelTester to run the standard weight tying regression test. Are you happy with that? 🙏

Can we instead create a small test for this? It seems that the original model did not have tied weights so this is more of an addition IMO and we check this as an explicit test (would be nice to link / mention your issue as well)

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

run-slow: mamba2

@vasqu Added an explicit regression test that checks both tie_word_embeddings=True and tie_word_embeddings=False 🙏

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

run-slow: mamba2

This comment contains `run-slow`, running the specified jobs: 

models: ["models/mamba2"]
quantizations: []

## CI Results
[Workflow Run ⚙️](https://github.com/huggingface/transformers/actions/runs/21260449250)

✅ No failing test specific to this PR 🎉 !
Mamba2ForCausalLM missing get_output_embeddings/set_output_embeddings breaks resize_token_embeddings
Author: Anri-Lombard
Pull request: no

### System Info
- transformers version: 5.0.0.dev0
- Python: 3.12

### Bug Description
`Mamba2ForCausalLM` does not implement `get_output_embeddings()` or `set_output_embeddings()` methods. This causes `resize_token_embeddings()` to fail silently - it resizes embeddings but not the `lm_head`.

### Reproduction
```python
from transformers import Mamba2ForCausalLM, AutoTokenizer

model = Mamba2ForCausalLM.from_pretrained("state-spaces/mamba2-130m")
tokenizer = AutoTokenizer.from_pretrained("state-spaces/mamba2-130m")

print(f"Before: embeddings={model.backbone.embeddings.weight.shape}, lm_head={model.lm_head.weight.shape}")

tokenizer.add_special_tokens({"additional_special_tokens": ["
"]})
model.resize_token_embeddings(len(tokenizer))

print(f"After: embeddings={model.backbone.embeddings.weight.shape}, lm_head={model.lm_head.weight.shape}")
# BUG: lm_head shape unchanged!
```

### Expected Behavior
Both embeddings and lm_head should be resized to the new vocab size.

### Suggested Fix
Add to `Mamba2ForCausalLM`:
```python
def get_output_embeddings(self):
    return self.lm_head

def set_output_embeddings(self, new_embeddings):
    self.lm_head = new_embeddings
```

Comments:
These methods are already inherited from `EmbeddingAccessMixin` via `PreTrainedModel`. The default implementation checks for `self.lm_head` which `Mamba2ForCausalLM` has (line 938).

Is there a specific case where this doesn't work?

Thanks for pointing out the inheritance @raimbekovm! 🙏

After investigation, you're right - the inherited methods work for the default case. The issue was specifically with `tie_word_embeddings=True`, where `_tied_weights_keys = {}` prevents weight tying from working.

Updating the PR with the proper fix.
Support initializing FakeTensors
Author: justinchuby
Pull request: yes

# What does this PR do?

Addresses https://github.com/pytorch/pytorch/issues/161636 by correctly constructing the kwarg for FakeTensors: in fake_tensors the device property is stored as "fake_device" when accessed via `__dict__`. However the initializer expects the device to be passed in as "device". This PR updates to logic to handle this special case.

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?

@Cyrilvallez

Comments:
I see in the issue mentionned that there are other errors - so let's wait on this until everything is resolved and we can see the whole picture!